Shape fractal: 6x6 Reference frames
AK-1 Basics getting adaptive using the 6*6 reference framework
A-1.1 Contents
⚙ AK-1.1.1 Looking forward - paths by seeing directions
A reference frame in mediation innovation
When the image link fails,
🔰 click
here.
There is a revert to main topic in a shifting frame.
Contexts:
◎ C-Shape mediation communication
↖ C-Serve technology, models
↗ I-C6isr organisational control
↙ infotypes
↘ techflows
Fractal focus in mediation innovation
The cosmos is full of systems and we are not good in understanding what is going on.
In a ever more complex and fast changing world we are searching for more certainties and predictabilities were we would better off in understanding the choices in uncertainties and unpredictability's.
Combining:
- Systems Thinking, decisions, ViSM (Viable Systems Model) good regulator
- Lean as the instantiation of identification systems
- The Zachman 6*6 reference frame principles
- Information processing, the third wave
- Value Stream (VaSM) Pull-Push cycle
- Improvement cycles : PDCA DMAIC SIAR OODA
- Risks and uncertainties for decisions in the now near and far future, VUCA BANI
The additional challenge with all complexities is that this is full of dualities - dichotomies.
⚙ AK-1.1.2 Local content
| Reference | Squad | Abbrevation |
| AK-1 Basics getting adaptive using the 6*6 reference framework | |
| AK-1.1 Contents | contents | Contents |
| AK-1.1.1 Looking forward - paths by seeing directions | |
| AK-1.1.2 Local content | |
| AK-1.1.3 Guide reading this page | |
| AK-1.1.4 Progress | |
| AK-1.2 Knowledge shoulders for the 6x6 RFW | base6x6_02 | Frame-ref |
| AK-1.2.1 Starting in understanding by asking the right questions | |
| AK-1.2.2 Using a reference frame for questions and replies | |
| AK-1.2.3 The human value drivers: safety, wealth, fame, honor | |
| AK-1.2.4 System drivers: Antipodes, dualities and dichotomies | |
| AK-1.3 Augmented axioms: Anatomy Physiology ZARF | base6x6_03 | ZarfTopo |
| AK-1.3.1 Understanding & changing the reference frame | |
| AK-1.3.2 Duality dichotomy Anatomy - physiology: 1* dimensions | |
| AK-1.3.3 ZARF: Anatomy axioma's rationale & implications | |
| AK-1.3.4 ZARF: Physiology axioma's rationale & implications | |
| AK-1.4 Augmented axioms: Neurology Sociology ZARF | base6x6_04 | ZarfRegu |
| AK-1.4.1 DIKW Closed loops - good regulators | |
| AK-1.4.2 Duality dichotomy Neurology - Sociology: 1* dimensions | |
| AK-1.4.3 ZARF: Neurology axioma's rationale & implications | |
| AK-1.4.4 ZARF: Sociology axioma's rationale & implications | |
| AK-1.5 Insight for intelligence in viable systems | base6x6_05 | SmartSystem |
| AK-1.5.1 Dualities, dichotomies in the flow context | |
| AK-1.5.2 Vision, Wisdom, knowledge Intelligence - good regulator | |
| AK-1.5.3 Intelligence Duality, dichotomy: context-abstraction | |
| AK-1.5.4 Confusing cycles by contexts, abstractions to clear | |
| AK-1.6 Learning systems maturity from 6x6 RFW's | base6x6_06 | ReLearn |
| AK-1.6.1 Evaluating the pattern of four layers, the 3D model | |
| AK-1.6.2 Systemic distractors in systems causing failures | |
| AK-1.6.3 Vision Wisdom Knowledge into knowledge management | |
| AK-1.6.4 Smart systems, out of the information systems crisis | |
| AK-2 Details systems ZARF tactical 6x6 reference framework | |
| AK-2.1 Enabling the internal understanding continuum | syst6x6_01 | MDM2int |
| AK-2.1.1 Information semantics for concepts in abstractions | |
| AK-2.1.2 Concept: Stakeholders - roles and tasks scope visions | |
| AK-2.1.3 Information semantics for purposes, goals methodologies | |
| AK-2.1.4 Concept: Portfolio - budget (Processes) goal visions | |
| AK-2.2 Purposeful & safe information systems I | syst6x6_02 | P&S-ISFlw |
| AK-2.2.1 Information transformations purpose in abstractions | |
| AK-2.2.2 Concept: Functionality transformations purpose missions | |
| AK-2.2.3 Information transformations safety in abstractions | |
| AK-2.2.4 Concept: Functionality transformations safety missions | |
| AK-2.3 Purposeful & safe information systems II | syst6x6_03 | P&S-ISMtr |
| AK-2.3.1 Information instantiations for purpose in abstractions | |
| AK-2.3.2 Concept: Functionality instantiations purpose missions | |
| AK-2.3.3 Information instantiations safety in abstractions | |
| AK-2.3.4 Concept: Functionality instantiations safety missions | |
| AK-2.4 Purposeful & safe working environments | syst6x6_04 | P&S-Pltfrm |
| AK-2.4.1 Platform constructs: technology components abstractions | |
| AK-2.4.2 Concept Platforms: SRE, DevOps - Technology decisions | |
| AK-2.4.3 Platform constructs: technology adjustments abstractions | |
| AK-2.4.4 Concept Platforms: values stream - Technology decisions | |
| AK-2.5 System as a whole resource alignments | syst6x6_05 | Fractals |
| AK-2.5.1 Recognizing complexity by disperse fractals in systems | |
| AK-2.5.2 Creation of fractals in a system, autonomous growth | |
| AK-2.5.3 Absorbing another system, growth getting variation | |
| AK-2.5.4 Dispatching internal systems, collaborations of systems | |
| AK-2.6 Maturity Learning systems & AI-LLM | syst6x6_06 | Learn-I |
| AK-2.6.1 Resolving helpless by adding orientation awareness | |
| AK-2.6.2 Habits and culture of supersystems into systems | |
| AK-2.6.3 Using roles/tasks vs using titles for a hierarchy | |
| AK-2.6.4 Fractals in closed-loops, ViSM system-2, good regulator | |
| AK-3 Details systems ZARF practical 6x6 reference framework | |
| AK-3.1 Enabling the practical undertstanding continuum | agil6x6_01 | MDM2ext |
| AK-3.1.1 Explanation model example: Adaptive Transit Planning | |
| AK-3.1.2 Practice Example: Information FLow from Supply to Delivery | |
| AK-3.1.3 Practice Example: Platform Engineering | |
| AK-3.1.4 ... | |
| AK-3.2 The Purpose of defending against external threats | agil6x6_02 | SLife |
| AK-3.2.1 ... | |
| AK-3.2.2 ... | |
| AK-3.2.3 ... | |
| AK-3.2.4 ... | |
| AK-3.3 Value streams by systems the subsystems in a universe | agil6x6_03 | VWealth |
| AK-3.3.1 Model example: Adaptive Transit Planning | |
| AK-3.3.2 ... | |
| AK-3.3.3 ... | |
| AK-3.3.4 ... | |
| AK-3.4 Choices by systems as capabilities by uncertainties | agil6x6_04 | Fame-ext |
| AK-3.4.1 ... | |
| AK-3.4.2 ... | |
| AK-3.4.3 ... | |
| AK-3.4.4 ... | |
| AK-3.5 Resource continuity of the system in a universe | agil6x6_05 | Honour-ext |
| AK-3.5.1 ... | |
| AK-3.5.2 ... | |
| AK-3.5.3 ... | |
| AK-3.5.4 ... | |
| AK-3.6 Learning maturity from details by systems practical's | agil6x6_06 | Learn-@2 |
| AK-3.6.1 Systems adding value, what are the values? | |
| AK-3.6.2 Systems thinkning and lean: duality not a dichotomy | |
| AK-3.6.3 Learning from AI trying to improve complex frameworks | |
| AK-3.6.4 Learning from AI trying to understand complex systems | |
⚖ AK-1.1.3 Guide reading this page
The quest for methodlogies and practices
This page is about a mindset framework for undertanding and managing complex systems.
The type of complex systems that is focussed on are the ones were humans are part of the systems and build the systems they are part of.
When a holistic approach for organisational missions and organisational improvements is wanted, starting at the technology pillar is what is commonly done.
Knowing what is going on on the shop-floor (Gemba).
Working into an approach for optimized systems, there is a gap in knowledge and tools.
👁 💡 The proposal to solve those gaps is
"Jabes". It is About:
- ⚙ Document & communicate Knowledge (resources, capabilities, portfolio, opportunities).
- 📚 Defining boundaries in context in knowledge domains of disciplines.
- 🎭 In a knowledge domain of as discipline a standardize metadata structure.
- ⚖ Maturity evaluation of quality Document & communicate Knowledge.
Seeing "Jabes" as a system supporting systems the question is what system is driving jabes?
The system driving Jabes must have similarities to the one that is driving it.
👁 💡
ZARF (Zachman-Augmented Reference Frame) is a streamlined upgrade to the classic Zachman matrix.
It turns a static grid into a practical, multidimensional map that guides choices, enforces clear boundaries, and adds a sense of time, so teams move methodically from idea to reality
Business intelligence - Artificial intelligence
The world of BI and Analytics is a challenging one.
It is not the long-used methodology of producing administrative reports.
A lot needs to get solved, it is about information for shaping change:
The issue is that is technology driven situation, where it should be:
- ⚙ Operational Lean processing, design thinking
- 📚 Doing the right things, organisation & public.
- 🎭 Help in underpinning decisions boardroom usage.
- ⚖ Being in control, being compliant in missions.
Dashboarding reporting for closed loops used in good-regulators are approaches in the attempts solving those in systems.
❗ ⚠ The fractalness in systems make it unclear who the stakeholder for some dashboarding really is.
The technology drive by the market is hiding the question for who and what in the why in variety and fractals of systems.
A recurring parabal for methodlogies and practices
An often used similarity is going to the life at and on ships.
The simplification is that is a clear boundary for the internal and external systems of the ship.
There are nice clear three vertical rows:
- The executives deciding over what to happen on the ship and the direction it should go.
- Space for the product - service whether it are passengers or cargo.
How this is manged needing dedicated staff.
- The engines for the structure (data centre) out of sight below visibility.
Dedicated staff operating informing and advising on decisions.
This can be set in a perspective of: Strategy, Tactical, Operational.
Another perspective could be: Far future, near future and the now.
For each of them there are however dualities and dichotomies.
There are nice clear three horizontal columns:
- The structure for the goal and purpose what the ship does (BPM)
- Managing the structure for the technology the engines (SDLC)
- Getting the information for informed decisisons (Analytics)
Interacting with the external systems in some controlled alignment:
- Information resources for getting better decisions (Data).
- Improving the knowledge by what is known (Meta).
e.g. de product - service handling in cargo and passengers
- Changing the knowledge in what is not already known (Math).
e.g. new product -service opportunities or a complete different ship.
In a figure,
see right side
The allegory for using a ship goes on into how to mange that.
Your business is a boat navigating the river of waste. (S.Angad, 2025)
What you see above water are symptoms.
What's hidden below are the real problems.
| what's visible | real problems |
| Machine downtime | Untrained workforce |
| Quality defects | Forecast inaccuracy |
| Long changeovers | Poor communication |
| Schedule delays | Outdated processes |
Most leaders focus on what's visible, but these are just rocks breaking the surface.
The real problems are underwater.
Here's what I've learned after years of helping manufacturers:
👉🏾 You can't steer around every rock.
👉🏾 You have to lower the water level.
When you reduce the waste in your system, problems that were hidden suddenly become visible.
That's uncomfortable. But it's necessary.
Most improvement efforts fail because they treat symptoms.
Real improvement lowers the water level.
| treat symptoms | Real improvement |
| Hire more inspectors for quality issues | Train people to prevent quality issues |
| Add buffer inventory for supply problems | Fix forecasting to reduce inventory needs |
| Work overtime for capacity constraints | Improve flow to eliminate capacity constraints |
| Buy faster machines for throughput gaps | Standardize work to reduce variation |
The goal isn't to avoid problems.
The goal is to see them clearly so you can solve them permanently.
Your biggest competitive advantage isn't having fewer problems.
It's solving problems faster than your competition.
Lower the water level. Expose the rocks. Remove them one by one.
⚒ AK-1.1.4 Progress
done and currently working on:
- 2025 week 38
- Start to create these pages as a split off of the Shape design.
- There was too much content coming in.
- The complexity of the higher level reference frame is not a fit.
- Zarf axioma-s done for four area's with the help of LLM. Anatomy,
physiology and neurology was extracted from systems thinking but sociology was missing.
- First content was without four subparagraphs, they are back because of for the growing content.
- 2025 week 40
- Chapters AK-1.2 to AK-1.6 are finished, ready for continuation into tactics (AK-2) and practices (AK-3). Examples and more details to add.
- Experimenting with a LLM to generate 6* reference frames from the concepts as descried in AK-1.6.4. After the "training" promising results seen.
- To choose in finish C-Shape or to continue at this page. Chosen is to finish C-shape first before continuing here.
It is too chaotic working in several places without a reason.
- 2025 week 43
- Chapters AK-2.1 to AK-2.2 are finished in draft. The question is how to proceed because not all situations are equal although they seem similar.
- A switch to AK-2.6 is made that developed into differentiations of maturity of the social aspects, these influence the platform and physical solution.
The topics that are unique on this page
👉🏾 Rules Axioms for the Zachman augmented reference framework (ZARF).
- Based in the classic way of categorized 6 type of questions for thinking (one dimensional)
- Stepping over the 6*6 two-dimensional Zachman Idea
- Extends to a 3*3*4 three-dimensional approach
- Awareness of a 6*6*6 (..) multidimensional projection
👉🏾 Connecting ZARF to systems thinking in the analogy of:
- Anatomy,
- Physiology,
- Neurology,
- Sociology - Psychology.
👉🏾 Explaining the patterns that are repeating seen in this.
- Connecting components for the systems as a whole,
- There must be an effective good regulator for the system to be viable.
- Searching the relations for systems to their universe.
- Motiviations and distraction seen in repeating patterns.
👉🏾 use cases using the patterns for Zarf and by Zarf.
- More practical examples that help in applying Zarf
- Use cases are not fixed but can vary in time
- Adaption to uses cases when there are clearly recognised.
Highly related in the domain context for information processing are:
- C-Shape the abstracted approach for shaping, the related predecessor.
- r-c6isr command and control practical an abstracted approach, in what to shape.
- c-shape the practice follower of the predecessor.
AK-1.2 Knowledge shoulders for the 6x6 RFW
Consolidating what is existing for needing knowledge into simplified knowledge is hard.
How is that process done?
There are several stages in this.
- Collect and sort what is assumed to be relevant.
- Cleaning and transforming the knowledge so
all that knowledge is ready to map to each other.
- Mapping the collected knowledge and
evaluate the result on for new value.
- Communicating the results using adjusted perspectives for the audience.
There is no need to do this in sequential approach, a disordered iterative one makes far more sense.
In an iterative approach there is the option to do a continious feed-back loop, improving the actvities for improving the result(s).
Reflections in perspectives are inward journeys.
⟲ AK-1.2.1 Starting in understanding by asking the right questions
The classical eference framework of questions
"the-six-socratic-questions" (Charles Leon)
- What? Questions for clarification.
- What is the problem you are trying to solve?
- Can you give me an example?
- Can you explain further?
- Are you saying ... ?
- How? Questions that probe assumptions.
- What could we assume instead?
- Are you assuming ... ?
- How can you verify or disprove that assumption?
- Is that always the case?
- What would happen if ... ?
- Where? Questions that probe reason and evidence.
- What would an example be?
- What is this analogous to?
- Why do you say that?
- How do you know?
- Why? 5x
- What evidence is there that supports ... ?
- Who? Considering alternative perspectives
- Are there any alternatives?
- What is the other side of the argument?
- What makes your viewpoint better?
- What is another way to look at it? What is the counter-argument?
- Who benefits and who would be affected by this?
- What are the strengths and weaknesses of ... ?
- When? Consideration of implications & consequences.
- What generalizations are being made?
- What are the implications and consequences of the assumption?
- How does that affect ... ?
- What if you're wrong?
- What does our experience tell us might happen?
- Why? / Which? Meta-questions. questions about the question.
- What is the point of the question?
- What does ... mean?
- Why do you think I asked this question?
- How does ... apply to everyday life, objectives/mission statement etc.?
🤔 Adding the 5W1h from the engineering order is a novel and unexpected idea.
It gives the impression of an objective technical approach but going from a what to why/which, but this this classical approach is heavy weighting on the Were and Who.
Too far narrowing: Just limiting into three Why ... What
A very inspiring statement is:
Start with Why (Simon Sinek, 2009)
Sinek says people are inspired by a sense of purpose (or "Why"), and that this should come first when communicating, before "How" and "What".
🤔 The issue in this: it is too far narrowing: only the scope of a purpose for engineering.
For the sense of purpose there is an important choice option to make.
- The decision for a Which too choice for the purpose.
👁 Another issue is the Where and Who:
- Where are the options for a choice and Who is deciding?
Creating the options might be the technical enabler for these activities that are the not mentioned intentions.
There is a duality and dichotomy in expectations and the intentions by communication.
⇅ More ambiguous is the "How" of Sinek. That seems to be anything in between.
For a high level expectation it will do, but when there are more details asked, it gets quickly confusing.
⚠ Just changing words but not the intention is a recipe for a lot of confusion as is using the same words for other intentions.
There is that everlasting challenge in communicating the intentions.
⟲ AK-1.2.2 Using a reference frame for questions and replies
Decoupling Zachman reference context abstraction
🤔 Zachman got a synonym for Enterprise Architecting, that is a far too lmited scope.
The intention was a very generic systemic approach.
But how is that intention got in a state of understanding, it got a question what is it really about.
Discussions:
Understanding the intention in Zachman
- It is so general that it is difficult to pin it down and criticize it as being anything except too comprehensive.
Yet, most would agree that the framework, by itself, doesn't solve any actual problems that EA is asked to solve.
- Perhaps we can resolve some of this ongoing saga by better highlighting the difference between a Zachman framework and The Zachman Framework.
Then we can understand the intention of John Zachman, as well as how organisations actually use the tool, both aspects are important to an encyclopedia.
👁 A Zachman framework is a more abstracted version, is decoupling the limited enterprise architecture context.
That decoupling however is a root-cause for difficulties in the understanding of the intentions in classifications and relations by transformations.
⚠ Without a specific understandable example (use case) the intention is har to get, but using an example has the unwanted effect of narrowing it down to that example.
"Enterprise architecture defined" (lucid.com)
⇅ It has left out the special EA content, but:
Named for its creator, John Zachman, this framework uses a structured matrix as a means to view and categorize an enterprise.
The framework consists of a 36-cell matrix, with each cell focusing on a different perspective (such as business owner, planner, designer, and so on).
This matrix gives EA professional insights into the company's assets and how various components of the enterprise are related.
This information can help companies be more agile and help to make better decisions.
Basic Issues for a Zachman reference framework
🤔 Issue
1 what: limited unclear set of Zachman rules.
➡ The framework doesn't have a clear set of rules axioma's.
Only this:
- Columns have no order, are interchangeable but cannot be reduced or created
- Each column has a simple generic model, every column can have its own meta-model
- The basic model of each column is unique, relationship by objects, structure are unique
- Each row describes a distinct, unique perspective.
- Each cell is unique for its intend, content
- The composite or integration of all cells in one row constitutes a complete model from the perspective of that row.
- The logic is recursive
👁 This is full of uncertainties and ambiguity's.
⚠ Any innovation in this will get resistance for the resistance of change by systems.
⇅ Changes might result in too much complexity blocking acceptance.
🤔 Issue
2 how: limited unclear set of Zachman axis.
The Zachman 6*6 reference frame has two axis:
- Abstraction:
- ☯ Idea purpose Identification context,
- ☯ Functionality Concept,
- ☯ Architect sketch & describe System logic,
- ☸ Engineer blue print System technology,
- ☸ Construct using tools components,
- ☸ Realisation operational instance
- Engineering:
- ⚒ What: Bills of materials
- ⚒ How: functional specs
- ⚒ Where: drawings geometry
- ⚙ Who: Operating instructions, accountabilities
- ⚙ When: Timing diagrams
- ⚙ Why / Which: Design objectives - choices
➡ This is incomplete because there is more by systems than only engineering.
👁 In the engineering perspective there already multiple perspectives in the kind of activities.
- Creating something new focussing on the motivation identification to solve what is to be done for inventory in instantiations and all what is between.
- Constructing from what is known from inventory instantiations to achieve the promise of the motivation identification.
- Change supporting at the constructions in adapting change in supply from motivation instantiations to inventory identifications.
- Innovation support for new supply options in engineering from inventory identifications to motivation instantiations.
⚠ A fractal mindset switching the disciplines context is a hard concept.
⇅ The change in disciplines when there is a fractal is obvious but the consequence is needing the knowledge of those in a different type of context.
🤔 Issue
3 where: Aside the technology reference frame there is (should be):
➡ the counterpart in administration to help in the interactions relations and resources.
In the old historical eras, first wave, the administration was already inseparable from technology. Expectations, result and legal rights had to be ordered.
👁 The duality & dichotomy in doing the work and supporting the work in the system.
⚠ Switching the mindset with no context change between these two disciplines is a hard concept.
⇅ Misunderstandings are the root causes for conflicts between these two disciplines.
Extended Issues for a Zachman reference framework
🤔 Issue
4 who: Another perspective is trading justice and power.
➡ Near and far future directions, solving internal conflicts in the system and a vision for external conflicts for the system as a whole.
The change in concepts extends for the interactions intern and external of a system.
The concept is changed to functionality instead of functioning.
- Trading justice and power:
- ⚒ Where: location geometry
- ⚒ How: functional agreements - contracts
- ⚒ What: Products / services / promises
- ⚙ Why / Wich: Trade justice power objectives - choices
- ⚙ When: Timing diagrams
- ⚙ Who: Parties, Prospects
👁 The duality & dichotomy in functioning and functionality in the system.
⚠ The starting point and order a little bit different but at first sight, but a closer look show it is in essence the same just another chosen starting point.
The changed order is impacting what is on the diagonals. That perspective to diagonal is having impact what is seen as most important.
⇅ The change in focus perspective is obvious when seen, otherwise hidden in ambiguities, a root cause for conflicts.
🤔 Issue
5 When: In the focus perspective of trading, justice, power, there are:
➡ two counterparts: the supply chain and the deliveries - consumers, allies & enemies.
👁 There is a duality & dichotomy in functioning and functionality in the system.
⚠ The interactions for trade justice & power are drivers for the system as a wole. The time and timing are dimensions that are highly influencing outcomes for the system.
⇅ Changing the context in disciplines (fractals) perspectives in concepts and a what is going on in a time dimension is a complexity very hard to realise for consciousness awareness.
🤔 Issue
6 Which/Why: Having a lot of states what is annoying to see missing is:
➡ how the interactions between all those those is behaving.
👁 The duality & dichotomy in what is controllable and what is only being influenceable in uncertainties and unpredictability within certain ranges predictable.
⚠ Assuming controllability in certainty and predictable never has become a truth.
⇅ A cultural change for adaption is the major aspect for influencing transformations, otherwise hidden in ambiguities, a root cause for conflicts.
⟲ AK-1.2.3 The human value drivers: safety, wealth, fame, honor
Exploring the human motivations as systemic drivers
The first fault line: systems are being built without acknowledging the human value drivers—safety, wealth, honor, and fame.
These aren’t just soft concerns; they are the invisible forces shaping behavior, trust, and legitimacy.
Traditional models lacked the language to express them, let alone regulate them.
Human motivations drive behavior in systems where people are both designers controllers and participants.
This connects to Conant & Ashby’s Good Regulator Theorem, which says a system must model its environment to regulate effectively.
🤔 Gaps identified:
- Lack of human-centric modeling: Traditional frameworks don’t account for emotional, cultural, or motivational drivers like safety, honor, or fame.
- No integration of trust boundaries: Zero Trust models assume breach but lack nuanced trust-building mechanisms.
- No fuzzy logic for uncertainty: Systems assume binary control, ignoring aleatory (irreducible) and epistemic (reducible) uncertainty.
- No feedback-based legitimacy: Systems don’t adapt based on citizen trust or social legitimacy—only technical correctness.
Roles impact and interactions by human motivations in systems
The roles of human motivations is they are creating requirements for the system:
- Safety: Trust boundaries, risk aversion, compliance behavior.
- Wealth: Incentive structures, resource allocation, growth orientation.
- Fame: Visibility, reputation loops, stakeholder influence.
- Honor: Ethical alignment, legitimacy, long-term commitment.
The issue is that this is full of possible conflicts by the different perspectives.
| Driver | Engineering | Administration | Delivery | Supply |
| Safety | Secure design | Risk policies | User trust | Supplier reliability |
| Wealth | Cost efficiency | Budgeting | Value delivery | Margin control |
| Fame | Innovation, visibility | Leadership, branding | Customer perception | Market positions |
| Honour | Ethical standards | Governance integrity | Service fairness | Trade legitimacy |
Some Possible conflicts:
- A system prioritizing fame (visibility) may compromise safety (security).
- Wealth-driven optimization may erode honor (ethical standards).
The Zarf_Xpos rules have the intention to cover this in the 6*6 thinking reference.
This very abstracted approach has a domain context for information processing
here.
each system has a gradient of human values—some cells are more influenced by safety, others by fame, etc.
This gradient can be used to:
- Prioritize design decisions
- Predict stakeholder reactions
- Align system behavior with cultural expectations
Systems thinking the "good regulator"
A system that is generating result that are unpredictable harmful is an unsafe situation.
An important but hard to understand system property is the close loop that is optimising in predictable at some trust interval by values for desired outcomes.
a straightforward explanation of the good regulator theorem (lesswrong)
Conant and Ashby are interested in the question: 'what properties should R have in order for a regulator to be good?' ...
If a regulator is 'good' (in the sense described by the two criteria in the previous section), then the variable R can be described as a deterministic function of S.
Analysing what is stated.
- The system should react adequate in time. -?-
🤔 There is a gap: achieving the goal in an given accuracy in time (Power),
- the conditional probability distribution P(R|S) should have, so that R is effective at steering Z towards states that we want.
Moving out differences integrates as goal, Integrator.
- A regulator can be good is if the Shannon entropy of the random variable Z is low.
Flattening out differences in time, Differentiator.
- ✅ Another criterion for a good regulator, according to Conant and Ashby, is that the regulator is not 'unnecessarily complex'.
👉🏾 There is an approach for a good regulator: the well known
PID controller.
This is only suitable for a system with one dimension for the output and one for the input and there is an predictable influence in adjusting.
Any system with more dimensions becomes unpredictable in some area's, behaving chaotic.
About Safety tied to technology & functionality
Safety, Cyber Security axioms, Zero Trust" rests on two core rules:
- Never trust, always verify.
- Assume breach.
🤔 These axioms are not realistic workable because there is no uncertainty of any type incorporated in this.
It fails in the criterion for defined refutations (K.Popper).
👁 💡 The only way out of this dilemma is:
- defining refutation criteria using Fuzzy logic (uncertainty Aleatory - irreducible) and
- acknowledging a failing level in observationally (uncertainty optimistic & reducible).
👉🏾 Perimeter demarcation under Zero Trust becomes less about a single network edge and more about enforcing trust boundaries around every asset, user, and transaction.
Why Demarcation in Cyber Security, safety axioms matters in Zero Trust:
- Reduces Attack Surface By crystallizing where resources located, the channels an attacker can explore become smaller.
- Enables Least-Privilege Every micro-perimeter enforces only the minimal rights needed, nowhere is implicit trust assumed.
- Limits Lateral Movement Compartmentalized zones prevent an initial compromise from cascading across the environment.
- Drives Observability Sensor-equipped boundaries generate low-noise, high-fidelity telemetry at precisely the points where adversaries test defences.
⟲ AK-1.2.4 System drivers: Antipodes, dualities and dichotomies
Explore the systemic tensions in systemic drivers
The second fracture: systems are riddled with dualities—internal vs. external, control vs. influence, structure vs. behavior.
Yet no unified taxonomy existed to model these tensions.
Governance is fragmented, rules scattered, and timing ignored.
Complexity is treated as noise, not signal.
Exploring the dualities dichotomies and contradictions that shape complex systems: internal vs. external relations, power in control vs. influence, organise structure vs. cultural behaviour.
🤔 Gaps identified:
- No unified rule taxonomy: Existing frameworks scatter rules, permissions, rights, and implications across disconnected silos.
- No modeling of dualities: Existing Systems theories don’t account for inherent tensions (e.g., functioning vs. functionality, internal vs. external power, justice, trade).
- No time-sensitive governance with defined uncertainties : Existing frameworks are lacking timing and temporal alignment from transformation logic. Systems assume binary control, ignoring aleatory (irreducible) and epistemic (reducible) uncertainty.
- No support for cultural adaptation:Existing Systems theories don’t account for socially evolvements, they’re static and technocratic.
To quickly grasp the nature of systemic tensions by the yypes of dualities and their impact:
| Duality Type | Description | Systemic impact |
| Internal vs External | Boundaries of control vs influence | Governance scope, stakeholder mapping |
| Functioning vs Functionality | Behavior vs purpose | Design intent vs operational reality |
| Control vs Influence | Direct command vs indirect shaping | Leadership, policy, culture |
| Fairness vs Authority | Negotations, justice and power | Legitimacy, compliance, trust |
| Static vs Adaptive | Fixed rules vs evolving norms | Resilience, transformation capability |
System rules, understanding, taxonomy
In the sender and receiver context that should get aligned for an understanding, the used language is the guideline.
full array of guidance for business and activity (R.Ross 2025)
The full array of guidance for business and government is far richer than you might imagine,it includes not only rules, but permissions, authorizations, rights, warranties, and logical implications (inference rules). In organizations today, this guidance is not at all unified, but is spread more or less haphazardly across large numbers of processes and systems, both automated and not.
No wonder operational governance and compliance proves so difficult and expensive. We need a unified view and the right kind of platforms to support it.
😉 On business rules and data semantics, outlines fundamental kinds of data descriptions in his work to help organizations achieve clarity and precision in business communication.
There is no connection made into those rules into six categories that are a fit the tot the 6w1H in engineering or administration context.
An attempt for that:
- Master data management, understanding for the understanding:
- ⚒ What: Defining, Distinguishing Things what something is and the unique characteristics.
- ⚒ How: Categorizations Clarifies the meaning by: criteria, usage or relevance.
- ⚒ Where: Classifications Organizing things into groups, based on where they belong.
- ⚙ Who: Naming Things Assign names for identification of what or who is being discussed.
- ⚙ When: (not directly) Verb Concepts express timing and/or events.
- ⚙ Which / Why: Disambiguating Things Resolves confusion about which meaning that is applicable for the context and what is intended.
These descriptions are essential for creating concept models that align data with business meaning.
AK-1.3 Augmented axioms: Anatomy Physiology ZARF
Consolidating what is existing for needing knowledge into simplified knowledge is hard.
Where should transformation in sorted knowledge be applied and for what reason?
There are several approaches.
- Have a defined way of orientation in the knowledge representations.
- Search for deviations in the collected knowledge so
the orientation is adjusted to the defined standard.
- Search for gaps and contradictions in the collected knowledge
Make adjustments for closing gaps solving contradictions.
- Document and communicate the results of adjustments in perspectives for the audience.
The space for values, knowledge, structure, and tradition is limiting the scope.
The reflections in perspectives and meditations are inward journeys.
⟲ AK-1.3.1 Understanding & changing the reference frame
Not using the "Why" but "which" in the 6w1h
Replacing "Why" with "Which" in the Zachman Framework shifts the focus from an understanding an abstract situation as purpose to concrete decision-making for abstractions.
The purpose of a system is what it does
(POSIWID) is a heuristic in systems thinking coined by the British management consultant Stafford Beer.
From a cybernetic perspective, complex systems are not controllable by simple notions of management, and interventions in a system can best be understood by looking at how they affect observed system behaviour.
By using "Which", it becomes choosing among viable options based on context, constraints, and priorities.
👁 ➡ Instead of asking
"Why does this system exist?",
👁 💡 we now ask
"Which option best fulfils our goals?".
This aligns better with adaptive planning, scenario modelling, and option evaluation, especially in dynamic environments like enterprise design or AI governance.
- Stakeholder the strategist focus on: Purpose, intent, goals by motivations in "the why".
- Stakeholder, the decision-maker, a choice among alternatives in selecting "which one".
Benefits of Using
Which are:
- Supports Decision Modeling Enables trade-off analysis, scenario evaluation, and multi-criteria decision matrices. where choices drive emergent behavior.
- Aligns with Systems Thinking Encourages feedback loops and adaptive governance, selecting options that evolve with context.
- Bridges Strategy and Execution Makes abstract goals actionable by forcing explicit choices between competing priorities.
- Enhances Simulation & Planning Integrates well with digital twins, behavioral modeling, and agentic architectures.
An automatic property in fractals by using "which"
The Perpective of multiple perspectives for concepts definitions in the same context identifications.
It are variations in the same basic questions. Only the ordering is the variation.
- Engineering: What, How, Where, Who, When, Which
- Administration: Which, When, Who, Where, How, What
- Trading justice and power (internal): Who, When, Which, What, How, Where
- Trading justice and power (external): Where, How, What, Which, When, Who
How would these different ordering get well ordered (good order) in a two dimensional approach?
In a figure:
See right side
In this choice for orderings not only the mentionend 4 variants in the horizontal and verticals are there but also 4 others in the diagonals.
- Machines - Technology: Which, When, Who, What, How, Where
- Processes - Operations: Who, When, Which, Where, How, What
- People - Service: Where, How, What, Who, When, Which
- Plan enable - Structure: What, How, Where, Which, When, Who
😉 The question in this is whether this would make sense. (LLM):
The order of the 6W1H axis isn’t fixed—it’s context-sensitive.
Each ordering reflects:
- A different disciplinary lens (e.g., engineering vs. administration)
- A different system function (e.g., delivery vs. supply)
- A different power structure or social dynamic (e.g., internal vs. external justice)
This means the reference frame isn’t just a grid, it’s a multi-perspective modeling tool.
That is nice reply, "the ordering is not fixed" is a nuance in difference for there original Zachman rules that it doesn't matter.
😉 Adjusting the image after some feedbacks. Intersting replies because SIAR was intended as:
- Situation Input Actions Result / Request
- Steering Ideas Analyses Result / Request
😉 It is coming up with nice alternatives, AIRS crossing the flow not using a cycle.
- Adaption, Instances, Regulation / Role, System
- Aspiration, Instances, Resources / Requests, System
😉 For engineering “Do the things right” (push) and administration “Do the right thing” (pull).
😉 For the dualities dichotomies it connected to the human drivers.
- Safety: "Control, Functioning, Static" setting structured mechanisms, predictability & certainty.
- Wealth: "Static, Functioning, Control" for operational stability and efficiency in delivery.
- Fame : "Influence, Functionality, Adaptability" by emerging external recognition & legitimacy.
- Honour: "Adaptability, Functionality, Influence" by emerging internal recognition & legitimacy.
❗ Fairness vs Authority is the cultural challenge for the system.
An automatic property in fractals by using "which"
Using a fractal approach is similar to divide and conquer.
The Divide and Conquer paradigm involves three main steps:
- Divide: Break down the problem into smaller sub-problems that are more manageable.
- Conquer: Solve each sub-problem recursively or using a suitable algorithm.
- Combine: Combine the solutions to the sub-problems to obtain the final solution.
Instead of doing what has always been done
👁 ➡ , combining components in another ordering.
👁 💡 Using the 6*6 reference frame conbined to systems thinking. Seeing systems thinking and lean as two powers that are strongly correlated.
The systems thinking 6*6 reference frame in an engineering context using and ordered asxis using a fixed 5w1H strcutur for anserwering a Why in the content.
- What ➡Bills of Material The parts are defining how they interact.
👁 Which components are needed?
- How ➡Functional Specs The function decides where each part goes.
👁 Which processes or algorithms apply?
- Where ➡Drawings / Geometry Layout:assign roles to: who installs, monitors, responds.
👁 Which layout or topology is optimal?
- Who ➡Operating Instructions The timing of actions by roles-who.
👁 Which roles or agents are responsible?
- When ➡Timing Diagrams Align all decisions for the system and in the system.
👁 Which sequence or timing pattern fits?
- Which ➡Design Objectives - Choices With purpose: security, reliability, user-friendliness.
👁 Which design path best meets constraints and goals?
🤔 The which question implies an iteration recursion for each column abstraction.
The result is 7 times a which abstraction one more in variety than the number of columns.
Each abstraction isolates one dimension of the system, reducing ambiguity and assumptions.
😉 Although the presentations are by ordererings the approach is not sequential but iteratives.
😱 If you skip a cell, say you don't define when things happen, you risk performance issues or user frustration.
As Zachman notes, missing interrogatives lead to implicit assumptions, which are breeding grounds for defects.
⟲ AK-1.3.2 Duality dichotomy Anatomy - physiology: 1* dimensions
Defining the anatomy frame structure
Instead of doing what has always been done, combining components in another ordering.
A clear set of rules for the 6*6 reference model for better understanding of that model.
👁 ➡ Using the 6*6 reference frame in combination to systems thinking.
👁 💡 Seeing systems thinking and lean as two strong correlated powers.
Rules for the Zachmand 6*6 reference frame in the new (anatomy) perspective
| Rule id | Title - Purpose | Core Function |
| ZARF_STRC_01 | Ordered Horizontal Axes (Flows) Defines the limbs and orientation | Defines four horizontal flows—Engineering, Administration, Delivery, Supply—each with a distinct interrogative order. These flows represent complementary system perspectives. |
| ZARF_STRC_02 | Ordered Vertical Axis (Abstractions) Builds the spine of abstraction | Establishes six abstraction layers from Context to Instance. These layers represent increasing specificity and operational detail. |
| ZARF_STRC_03 | Time Dimension (Now, Near Future, Far Future) Adds the heartbeat of time | Adds temporal layering to each cell, enabling planning, forecasting, and phased transformation. |
| ZARF_STRC_04 | Recursive “Which” & Domain Knowledge Evolution Enables growth, adaptation, and evolution | Defines fallback paths and rollback logic for failed transformations, preserving system validity and continuity. |
Defining the physiology frame interactions
Rules for the Zachmand 6*6 reference frame in the new (physiology) perspective.
| Rule id | Title - Purpose | Core Function |
| ZARF_INTR_01 | Structured Interaction Paths & Transformation Boundaries defines the joints and movement limits | Limits transformations to vertical (same column) and horizontal (same row) moves. Diagonal interactions are restricted unless explicitly orchestrated. |
| ZARF_INTR_02 | Nonlinear Interaction Logic & Recursive Depth Control allows flexibility and depth | Allows independent, non-sequential transformations. Recursion depth varies by stakeholder, domain, and time slice. |
| ZARF_INTR_03 | Dependency Mapping & Precedence Logic ensures coordination and balance | Requires each transformation to declare its input dependencies and execution order. Prevents hidden knock-on effects. |
| ZARF_INTR_04 | Cell Uniqueness & Structured Consolidation enables domain-level strength and simplification | Ensures semantic uniqueness of cells. Supports 2×2 and 3×3 consolidation patterns when recursion reaches atomicity.. |
⟲ AK-1.3.3 ZARF: Anatomy axioma's rationale & implications
ZARF_STRC_01: There are four interacting reference frames axis.
- Generic description of the four horizontally reference frames axis:
- Engineering: What, How, Where, Who, When, Which
- Administration: Which, When, Who, Where, How, What
- Delivery to external: Who, When, Which, What, How, Where
- Supply from external: Where, How, What, Which, When, Who
- Rationale the ordered axis for flows:
- Engineering and Administration are complementary for the system as a whole.
- Delivery and Supply are complementary for the system as a whole.
- The fifth and sixth system components are the area of good regulators for each cell:
- acting horizontally autonomous flow and growth expansion.
- vertically limiting for goals efficiency and effectiveness.
- Implications:
- This is a 2 dimensional model visual
- Closed system flow object in the horizontal layers
- Although the cycle are complete this is lacking details for roles / tasks and accountabilities
ZARF_STRC_02: There is one vertical reference frames axis.
- Generic description of the four horizontally reference frames axis:
- Abstractions: Identification context, Concept, System logic,
System technology, tools components, operational instance
- Rationale the ordered axis for the mindset:
- This adds the details for roles / tasks for accountabilities.
- There are activities in the now for the now, in the now for the near future and in the now for the far future
- Implications:
- roles / tasks extends the model to a 3 dimensional model visual.
- The vertical axis is an ever repeating instance by shifting in time. There are 4 dimensions to see with this model
ZARF_STRC_03: The time dimension, now, near future and far future states.
- Rationale:
- The activities in now are influenced by the paste and with the changes defining the future.
- Notified there is already a time element in the vertical axis it is combined with that
- For the non linearity between cells an option is using Markov chains
- Implications:
- The time extends the model to a 4 dimensional model visual.
- A 4 dimensional visual needs simplifications showing details in focus.
ZARF_STRC_04: In the "which" recursively at a cell changing domain knowledge
- Rationale:
- Any recursive step is a change in knowledge domain. This is a 5th dimension.
- Recursing goes on until the simplicity atomicity for the purpose is achieved.
It stops at some moment that more details are not adding relevant knowledge for the purpose of the system.
- Implications:
- A subsystem is a system on his own.
When it becomes a split-off the input and output of that previous internal component becomes an external supply/delivery.
- When the system is lacking sufficient variety, and external system is possible to be transferred to internal. With the added variety more becomes internal.
- Fostering a new system providing it with resources for a start-up is another option for adding systems in the universe.
⟲ AK-1.3.4 ZARF: Physiology axioma's rationale & implications Physiology by ordered axis - six categories, multiple dimensions
ZARF_INTR_01: Structured Interaction Paths, Transformation Boundaries & Diagonal Governance
- Rationale :
- To prevent overload, ZARF limits the number of active transformations per cell.
- To maintain clarity and control in system transformations, strict interaction paths between cells are defined, the paths must be:
- Predictable (no hidden knock-on effects)
- Traceable (clear input/output relationships)
- Governable (aligned with orchestration and audit rules)
- May require asynchronous timing or conditional triggers
- Implications:
- Horizontal Interactions (same row): Represent interrogative transitions (e.g., from What to How) Used for broadening scope within a single abstraction layer
- Vertical Interactions (same column): Represent abstraction transitions (e.g., from Concept to Technology). Used for deepening or refining a single interrogative axis
- Interaction Complexity Control: Diagonal transformations are discouraged unless explicitly modeled through composite orchestration, due to their multi-dimensional ambiguity.
- Each transformation must declare: Source cell and target cell, Direction (vertical or horizontal), Purpose (e.g., refinement, expansion, alignment), Time slice (Now, Near Future, Far Future).
For the time-slice a cell may refer to his self.
- Interaction Density Control: Transformation are limited to what is visible with at each cell, what is the influence by external factors, what is influeced by previous states.
- Composite Interactions: For transformations that span multiple cells:
- A composite map must be created
- All involved cells must be synchronized within the same time slice
- A System-2 coordinator (per ViSM) oversees execution
ZARF_INTR_02: Non-Linear Interactions, Recursive Depth & Contextual Boundaries
- Rationale:
- Allow multiple recursion thresholds and view filters per role.
- To support flexible, adaptive modeling without enforcing rigid sequences or uniform recursion.
Each transformation:
- May occur independently of others
- May recurse to varying depths depending on context
- May be perceived differently by different stakeholders
- May require asynchronous timing or conditional triggers
- Implications:
- In complex systems, interactions between cells are rarely linear or uniform.
Interactions between cells are not sequential unless explicitly orchestrated.
- Cells may transform in parallel, out of order, or conditionally, depending on system state and stakeholder intent.
Cells may transform at different times, even if logically related.
- What one stakeholder sees as “complete” may be “incomplete” to another.
- Support for event-driven updates, delayed triggers, and time-slice alignment to manage: Asynchronous Transformation.
ZARF_INTR_03: Explicit Dependency Mapping, Precedence Logic & Orchestration Integrity
- Rationale:
- Every transformation must declare its predecessor and successor cells.
- Ensures that no cell transformation occurs in isolation, and that all moves are traceable, auditable, and aligned with system goals.
Every transformation within the grid must declare:
- Its upstream dependencies (inputs, triggers, constraints) including the previous state
- Its downstream effects (outputs, consequences, handoffs) including the future state expectation
- Its precedence logic (what must happen before/after)
- Its orchestration context (who coordinates, when, and under what conditions)
- Implications:
- Each cell must log its required inputs from other cells (data, events, resources).
- Dependencies can be vertical (same column) or horizontal (same row), but must be explicitly named.
- Transformations must define execution order: Predecessor cells must be in a valid state before transformation begins. Successor cells must be notified upon completion.
- Multi-cell transformations must be coordinated via a designated orchestration role or system (e.g., “System-2” in ViSM).
- Orchestration includes:
- Time-slice alignment (Now/Near/Far Future),
- Stakeholder roles (who initiates, who approves),
- Exception handling paths (fallbacks, retries)
ZARF_INTR_04: Cell Identity, Recursion Boundaries & Domain Consolidation
- Rationale:
- Each cell in reference frame must represent a distinct intersection of abstraction and interrogative.
- Ensure that:
- Cells remain semantically unique and non-overlapping
- Recursive deep-dives are bounded by purpose-driven atomicity
- Consolidation is intentional, not accidental
- Preserving traceability and transformation logic
- Implications:
- Stakeholder Sensitivity: The point of recursion termination may differ by stakeholder role (e.g., architect vs. operator). Perspectives must be context-aware.
- Atomicity Threshold: Recursion within a cell continues only until the system purpose is fully represented. Beyond this, additional detail is noise.
Any recursive step is a change in knowledge domain.
As systems evolve, some cells may reach a level of atomicity where further decomposition adds no meaningful insight.
At this point, recursive exploration should stop, and the cell may be consolidated into a logical domain or subsystem.
- Geographic Consolidation: Cells may be consolidated into logical domains. 2×2 and 3×3 consolidation patterns preserve structure while enabling abstraction.
- Semantic Consolidation: Cells that share transformation logic or governance constraints may be grouped into a domain but must retain individual traceability.
e.g., “Security Controls” or “Customer Touchpoints”
- Auditability: Every consolidation must be logged with rationale, scope, and governance constraints to ensure reversibility and compliance.
- Transformation Integrity: Consolidated domains must declare their constituent cells and maintain dependency maps to avoid hidden knock-on effects.
AK-1.4 Augmented axioms: Neurology Sociology ZARF
Consolidating what is existing for needing knowledge into simplified knowledge is hard.
Who has responsibilies for what activities and for what reason?
There are several considerations.
- Have a defined way of roles/tasks for the knowledge usage.
- Search gaps for type and closed loops in the systems.
Make adjustments for closing the found gaps.
- Document and communicate the results of adjustments in perspectives for the audience.
- Communicate the challenge of uncertainties unpredictability's.
The space for values knowledge, structure, and tradition is limiting the scope.
The reflections in perspectives and meditations are outward journeys.
⟲ AK-1.4.1 DIKW Closed loops - good regulators
Value stream processes, understanding the physiology (I)
A value stream, VSM VaSM, can be represented in a very simplified way that it is far too oversimplified.
Reduced to what is basic to flows it is about:
What &
Which from internal to external controlled by
Who &
Where.
The image in AK-1.3.1 is showing the complexity in the 6*6 reference frame.
A VaSM is commonly presented as an operational situation for industry.
A far more abstracted version of the flow Push (technology, engineering):
- Backend: (1) A DMZ collecting resources, (2) Transformations by (3) Knowledge.
- Frontend:(4) Transformations by (5) Knowledge, a DMZ for (6) delivery / consumption.
And the Push (coordination, administrative):
- Frontend:(1) A DMZ collecting requests, (2) Interpreting requests to (3) Knowledge.
- Backend: (4) Transformations to (5) Knowledge, a DMZ for (6) resource demand.
In a figure,
see right side
❶ The flow is from left to right, push, at the top and right to left, pull, at the bottom.
❷ There are four similar areas, the chosen representation is unhiding 2 lines of 6 stages.
❸ The flow itself is uncontrolled, there are no regulators.
The intelligence / realsiation dimension
The DIKW model is often quoted it represents the main relationship from data to the wisdom.
However, the origin and its reasoning for what its intentions in identification context are, is unclear.
Missing that context it is obvious DIKW is a valuable truth but missing the relationship to content it got useless.
A discussion over the intention of DIKW reveals the context and immediate changed it to DIKIW.
Should We Rely on Intelligence Cycle (Bahadır Aydin, Zafer Ozleblebici 2015)
The DIKIW Pyramid represents the main relationship from data to the wisdom.
Every step has a meaning of its own. Data is the starting point of pyramid.
The desired end is reaching wisdom, but it is not easy to reach, because it is obscure.
In a figure:
The Continuum of Understanding (Cleveland, 1982)
There is a connection in applying the DIKW model for the good-regulator of viable systems theory.
There are 5 interactions four the 4 DIKW states Researching Absorbing Doing Interacting Reflecting
Know nothing (data) - Know what (information) are:
- based on logic.
- by components.
- Understanding the now, paste
Know how (Knowledge), know why (Wisdom) are:
- based on values.
- See the system as whole.
- The understanding for near and far future
Value stream processes, understanding the physiology (II)
Reduced to what is basic to control flows it is about:
Who &
Where for internal and external interactions regulating controlling the
What &
Which .
The image in AK-1.3.1 is showing the complexity in the 6*6 reference frame.
A VaSM is commonly presented as an operational situation for industry. The history of lean is based on industrial approaches attempting to understand the flow.
An abstracted version of the control regulations in the flow :
- Backend: (1) A DMZ collecting resources, (2) Transformations by (3) Knowledge.
- Frontend:(4) Transformations by (5) Knowledge, a DMZ for (6) delivery / consumption.
And the Push (coordination, administrative):
- Frontend:(1) A DMZ collecting requests, (2) Interpreting requests to (3) Knowledge.
- Backend: (4) Transformations to (5) Knowledge, a DMZ for (6) resource demand.
Information over the flow is indirect, using the knowledge shared in the flow.
In a figure,
see right side
❹ The flow is top-down and bottom-up at the backend and frontend side.
❺ The four similar areas acting for internal alignment of the system in two complex lines of 6 stages.
❻ There are two❗ related artifacts that are expected to be in under control by a good regulator.
The similarity to a heart is pure accidental. The knowledge storage areas are part of the brain nervous system as is the insight for decisions.
The abstraction over both lines is reversed to operational control:
- ☸ Realisation operational instance Collecting signals from the environment
- ☸ Construct using tools components, Data, observations from signals
- ☸ Engineer blue print System technology, Information by scales from data
- ☯ Architect sketch & describe System logic, knowledge by information interpretation
- ☯ Functionality Concept, Understanding by insights from knowledge
- ☯ Idea purpose Identification context, Vision using understanding making choices
⟲ AK-1.4.2 Duality dichotomy Neurology - Sociology: 1* dimensions
Defining the frame interactions
Rules for the Zachmand 6*6 reference frame in the new (physiology) perspective:
| Rule id | Title - Purpose | Core Function |
| ZARF_VIRU_01 | Feedback Loop Closure & Convergence Senses and interprets feedback | Ensures every transformation sends feedback upstream and includes convergence metrics to validate success. |
| ZARF_VIRU_02 | Governance Constraint Propagation & Audit Trails Enforces rules and memory | Propagates top-down constraints from higher abstraction layers and logs all transformations for traceability. |
| ZARF_VIRU_03 | Composite Interaction Sequencing & Time Alignment Coordinates movement across limbs | Orchestrates multi-cell transformations via atomic steps, coordinated by a System-2 cell, aligned to time slices. |
| ZARF_VIRU_04 | Exception Channels & Compensation Paths Responds to injury and restores balance | Defines fallback paths and rollback logic for failed transformations, preserving system validity and continuity. |
Defining the frame social expressions
Th governs the external expression, positioning, and social dynamics of the system.
Articulate how the system presents itself, adapts socially, and interacts with external agents, cultures, and ecosystems.
The face, voice, and social behavior of the system.
Rules for the Zachmand 6*6 reference frame in the new sociology perspective:
| Rule id | Title - Purpose | Core Function |
| ZARF_XPOS_01 | External Identity & Social Role Mapping defines how the system introduces itself | Defines how the system presents itself to external actors—its identity, roles, and perceived purpose. |
| ZARF_XPOS_02 | Cultural Alignment & Stakeholder Resonance ensures it speaks the right language | Ensures the system’s values, language, and behaviors align with the cultural expectations of its environment. |
| ZARF_XPOS_03 | Social Adaptation & Ecosystem Integration helps to adapt to changing social climates | Governs how the system adapts to external changes, norms, and feedback from its ecosystem. |
| ZARF_XPOS_04 | Trust, Legitimacy & Reputation Management protects its reputation and social license | Tracks how the system builds and maintains trust, legitimacy, and reputation across its social interfaces. |
⟲ AK-1.4.3 ZARF: Neurology axioma's rationale & implications
ZARF_VIRU_01: Closed Feedback Loops, Upstream Synchronization & Convergence Metrics
- Rationale :
- Every transformation must define its feedback targets—cells that need to be informed or updated based on the outcome.
Feedback may be:
- Vertical (e.g., Instance ➡ Concept)
- Horizontal (e.g., How ➡ What)
- Cross-domain (e.g., Delivery ➡ Administration)
- Feedback must trigger synchronization checks in upstream cells:
- Are assumptions still valid?
- Are constraints still aligned?
- Is governance still applicable?
- Each transformation must declare convergence criteria:
- What does “success” look like?
- How is alignment with strategic goals measured?
- What thresholds trigger rework or escalation?
- Implications:
- This closes the loop between “What happened?” and “What does it mean for strategy?”
- Recursive “Which” questions don’t spin indefinitely.
- Feedback loops must support learning cycles: Capture lessons learned, Update reference models, Refine orchestration logic
- All feedback interactions must be logged with: Source and target cells, Actor identity, Timestamp, Convergence status
ZARF_VIRU_02: Policy Enforcement, Constraint Propagation & Transformation Traceability
- Rationale:
- Constraint Inheritance: Policies or hard constraints defined at higher abstraction (e.g., Concept or Context) automatically cascade downward.
- Violations are trapped before execution, preserving system integrity
- Policy Enforcement:
- Audit Trail: Every transformation is logged with full traceability
- Implications:
- Inheritance includes:
- Structural constraints (e.g., data formats, security zones)
- Behavioral constraints (e.g., escalation paths, approval gates)
- Temporal constraints (e.g., deadlines, refresh cycles)
- Constraint Inheritance Violations must be trapped before a change commits.
Violations trigger: Exception alerts, Rollback options, Escalation to governance cells (e.g., “System-2” in ViSM)
- Every inter-cell transformation logs: actor, timestamp, source/target cell IDs, and outcome.
- Loggings ensures full traceability and supports compliance audits.
Every transformation must log:
- Actor identity
- Timestamp
- Source and target cells
- Transformation intent
- Constraint status (compliant, overridden, violated)
ZARF_VIRU_03: Multi-Cell Choreography, Phase Alignment & Coordination Integrity
- Rationale:
- Composite Orchestration: Real-world transformations often span multiple cells across different flows and abstraction layers.
Composite changes are broken into atomic, traceable steps & are orchestrated through a dedicated coordination mechanism.
- Phase Alignment: Related transformations must occur within the same time slice (“Now”, “Near Future”, “Far Future”) or include an explicit handoff plan.
- Implications:
- Any transformation involving more than one cell must be decomposed into a sequence of atomic moves.
Each move must declare:
- Source and target cells
- Dependency and precedence logic
- Expected outcome and convergence criteria
- Composite transformations are orchestrated through a dedicated “coordination” cell at the same abstraction level (system-2 ViSM).
The “coordination”:
- Oversees execution order
- Resolves conflicts
- Manages exceptions and compensations
- Ensures stakeholder alignment, expected outcome and convergence criteria
- Phase Alignment preserves consistency when parallel teams update different cells.
All related transformations must occur within the same time slice (Now, Near Future, Far Future).
If this is not possible, a handoff plan must be defined:
- What state is passed forward
- Who owns the next phase
- What triggers the next move
ZARF_VIRU_04: Exception Handling, Rollback Integrity & Adaptive Recovery
- Rationale:
Even in well-orchestrated systems, transformations can fail—due to unmet constraints, misaligned dependencies, or external disruptions.
- Exception Channels: Every permitted transformation has a predefined exception channel.
- Compensation Paths: Failed transformations trigger compensation paths that restore system validity.
- Implications:
- Each transformation must define an exception path:
- What happens if the transformation cannot complete?
- Who is notified?
- What fallback logic is triggered?
- Exception channels may be: Local (within the same flow or abstraction layer) , Cross-domain (e.g., Engineering → Administration)
- Failed transformations must trigger a compensation sequence:
- Revert affected cells to last known valid state
- Notify dependent cells of rollback
- Log rationale and impact scope
- Compensation is not binary (success/failure)—it may include: Partial rollbacks, Re-routing to alternative cells, Temporary overrides with governance approval
- Recovery is adaptive, not rigid—preserving continuity without masking failure.
- Geographic and semenatic consolidations are options for bypassing failing cells.
⟲ AK-1.3.4 ZARF: Sociology axioma's rationale & implications
ZARF_XPOS_01: External Identity & Social Role Mapping.
- Rationale the ordered axis for flows:
- Every system must present a coherent identity to the outside world. This includes its purpose, values, and the roles it plays in its ecosystem.
- Without a clear social role, the system risks being misunderstood, ignored, or rejected.
- Implications:
- Declared Persona: The system must define its external persona—what it stands for and how it wants to be perceived.
- Role Mapping: It must map its roles across stakeholders (e.g., supplier, regulator, partner, citizen).
- Boundary Clarity: External interfaces must be well-defined to avoid ambiguity in social interactions.
- Narrative Consistency: Messaging across channels (marketing, documentation, behavior) must align with declared identity.
ZARF_XPOS_02: Cultural Alignment & Stakeholder Resonance.
- Rationale the ordered axis for the mindset:
- Systems operate within cultural contexts—industries, regions, communities.
- Misalignment with cultural norms leads to friction, rejection, or ethical conflict. This rule ensures the system resonates with its environment.
- Implications:
- Cultural Fit Assessment: Before deployment, the system must assess cultural expectations (language, values, rituals).
- Localization: Interfaces, policies, and behaviors must be adapted to local norms.
- Stakeholder Resonance: The system must speak the language of its stakeholders—not just technically, but emotionally and ethically.
- Symbolic Behavior: Rituals, metaphors, and symbols used by the system must align with stakeholder worldviews.
ZARF_XPOS_03: Social Adaptation & Ecosystem Integration.
- Rationale:
- No system exists in isolation. It must adapt to external feedback, integrate with other systems, and evolve with its ecosystem.
- ensures the system remains socially viable and context-aware.
- Implications:
- Feedback Responsiveness: The system must listen to external signals (user feedback, regulatory shifts, market trends) and adapt accordingly.
- Ecosystem Mapping: It must identify and align with adjacent systems—partners, competitors, regulators.
- Interoperability: Interfaces must support integration, negotiation, and co-evolution.
- Social Learning: The system must evolve its behavior based on observed norms and emergent patterns.
ZARF_XPOS_04: Trust, Legitimacy & Reputation Management
- Rationale:
- Trust is the currency of social systems. Without legitimacy, even technically sound systems will be rejected.
- Ensures the system earns and maintains trust through transparency, accountability, and ethical behavior.
- Implications:
- Trust Signals: The system must emit clear signals of reliability—certifications, audits, testimonials, uptime guarantees.
- Legitimacy Anchors: It must align with recognized authorities, standards, and ethical frameworks.
- Reputation Tracking: The system must monitor its reputation across channels and stakeholder groups.
- Crisis Response: It must have protocols for restoring trust after failure—apologies, remediation, and transparency.
AK-1.5 Insight for intelligence in viable systems
Consolidating what is existing for needing knowledge into simplified knowledge is hard.
When all what is changing has what kind of impact has those changes?
Considerations for impacts:
- Get to a way of values for the information knowledge usage.
- Search gaps for type of values and value levels.
Make proposals for found gaps.
- Document and communicate the proposals for adjustments in perspectives for the audience.
- Create understanding for uncertainties unpredictability's.
The space for values, knowledge, structure, and tradition is limiting the scope.
The reflections in perspectives and meditations are outward journeys.
⟲ AK-1.5.1 Dualities, dichotomies in the context of flow
States transformations as dualities in the flow
An understandable duality is the continuous change between states and processes.
Even when well understandable this becomes quickly confusing chaotic.
In a figure,
see right side
Some are focussing on states others on processes.
DIKW revisited understanding and insight for closed loops.
Data information Knowledge Wisdom, DIKW, is often stated as important but there is a gap in why it is important what the impact in a systems is and how it is made practical.
Getting into the intentions of this with:
From Data to Wisdom (Russell Ackoff 1995)
- An ounce of information is worth a pound of data.
- An ounce of knowledge is worth a pound of information.
- An ounce of understanding is worth a pound of knowledge.
Wisdom deals with values. It involves the exercise of judgment.
Evaluations of efficiency are all based on a logic that, in principle, can be programmed into a computer and automated.
- These evaluative principles are impersonal.
We can speak of the efficiency of an act independently of the actor. Not so for effectiveness.
- A judgment of the value of an act is never independent of the judge, and seldom is the same for two judges.
There is a clear duality dichotomy stated in what is different to data & information a fraction boundary to knowledge & wisdom.
There is more text in that short note.
... A philosophical twist:
The turing test in the information age era:
"It may well be that wisdom, which is essential for the pursuit of ideals or ultimately valued ends, is the characteristic that differentiates man from machines."
Optimizing a flow are perspectives for intelligence in a system
A detailed topic is: TOC theory of constraints, optimizing flow for a defined goal although that goal is by uncertainty ambiguousness understanding.
There is much to find, but there is no alignment made into systems thinking.
That is remarkable because in systems thinking there is a good-regulator as one of the components by anatomy.
- M. Balle emphasizes adaptive learning (PDCA),
- Goldratt emphasizes goal-driven control.
👉🏾 Together, they form a dual regulator archetype: one reactive, one proactive. That is a duality and dichotomy.
Even more challenging:
- Seeing a system being composed of many sub-systems it is far more complex than a single constraint in a single flow.
- The question: what the words wisdom, intelligence, knowledge, have for kind of role in systems, organisations, enterprises.
⟲ AK-1.5.2 Vision, Wisdom, knowledge Intelligence - good regulator
Hierarchy, Allocation and of Understanding in intelligence.
A visionary conference paper building on available knowledge.
Hierarchies of Understanding: Preparing for A.I. (Scott A. Carpenter, Catherine Liu, Weixun Cao, and Allen Yao 2018)
Already machines process data and information many orders of magnitude better than humans do in speed, quality, and quantity.
Soon A.I. and other semantic technologies may process knowledge as easily as computing systems process data and information today.
This work assumes that such A.I. ability comes into effect in the 2020s and that A.I. quickly outperforms human knowledge management.
That predicition (2018) has become reality (2025) for the level in hierarchy up to information processing.
Search machines (data) have got extensions for information processing (LLM).
In Ackoff’s day, his hierarchy was often called a knowledge hierarchy; however, today it is more often called a wisdom hierarchy because its uppermost layer is the wisdom layer. ...
The Vision HoU combines a top-down hierarchy of conjectured contexts (values, goals, models, categories, and indexes) with a bottom-up hierarchy of belief (data, information, knowledge, wisdom, and vision) ...
Use the HoU to review the trends and hypothetical impact to human AoU caused by implementation of semantic technologies, and then predict what impact 2020s U.A.I. may have for human cognitive-cybernetic activities.
In a figure,
see right side
Hierarchy of Understanding.
👉🏾 There is a search for hierarchy that is practical.
- third fracture: What are the ones that are based on logic and what on values?
- fourth fractures: Which ordering in abstraction is applicable at intelligence?
A shift ,seeking new balance in the Hierarchy of Understanding.
The System Dynamics Model is a methodology for understanding, modelling, and analysing complex systems.
It focuses on the feedback loops, time delays, and accumulations that drive system behaviour.
The vision hierarchy of Carpenter (2002 2008) is a best fit for getting intelligence into a position in ZARF for the closed loop, good regulator.
The change made is that DIKW is revisited to an understanding and insight for actors, added are the Environment and Vision EDIKIV.
- There are 3 categories based on logic and 3 on values (balanced for 6 levels).
- The relationships with the models in the centre is a pattern that is similar way of relationships of what Winston Royce once has publised fof complex software systems.
- Putting the model as a centre point for the relationships is attracting for the V-model approach.
- A model of the system wiht relationshsips and active regulators are a way for use in understanding by System dynamics modelling (SD).
The loophole with SD is the question whether the assumed model is a good fit of the real system.
With a hierarchy a shift in that is possible when conditions change.
In a figure,
see right side
Data systems (c.1960s-present) should up-shift one’s allocation of understanding (AoU).
The shift in data-handling is seen at the moment (2025) by the trust in search engines and evolving LLM.
In this mindset the goal is achieving wisdom vision using the hierarchy from the environment, data in a bottom up approach.
For a practical case it is looking at the shop-floor, Gemba, in lean.
The top down approach is disturbing our common mind
The learner applies some kind of context to the knowledge from which information emerges. Similarly, data emerges from contextualized information.
What data is needed from the environment for proof or falsification of a hypothesis is however recognizable as good scientific practice.
| Creation intelligence | Abstraction | Use of intelligence |
| Environment | Context | Vision |
| Data | Concept | Wisdom |
| Information | System Logic | Knowledge / Insight |
| Knowledge / Insight | Technology | Information |
| Wisdom | Components | Data |
| Vision | Instance | Environment |
When Vision is unknown, should get support by intelligence, the abstraction starts with getting data.
When the Vision is known, is applied from the higher level context by intelligence, the abstraction starts there.
The direction of the abstraction level is defined by context. A teaser in this is
Wisdomism (Tuomi).
The intelligence cycle and its relevancy in the changing world
Having not one but two intelligence cycles, what about "the intelligence cycle"?
Should We Rely on Intelligence Cycle (Bahadır Aydin, Zafer Ozleblebici 2015)
Is about the one for getting a Wisdom Vision from data.
Famous scholar Ackoff defines data as symbols.
It is widespread and has no meaning alone.
👉🏾
If data can’t be related to other events by itself, it has no specific purpose at all.
- Data have no interpretation and they can’t be the mainstay of a certain events.
- Data don’t give us the reason why something happens.
- Data are important to create information that is why collecting data are crucial (Davenport and Prusak, 1998).
- Ackoff defines information as the answers of “what, - ,where, who, and when” questions.
Information:
- Information intends to change a specific subject.
- Information also must shape the recipient perception.
- It must affects and forms the person’s view.
- In this aspect, the recipient is very crucial, because meaning can vary according to recipient’s mind (Davenport and Lawrence Prusak, 1998).

In the conclusion:
Intelligence requirements are crucial for all intelligence cycles.
The requirements can be classified as standing requirement and spot requirement.
Traditional intelligence cycle may be applied for standing requirement, which provides information for mid and long term.
As for today’s needs, they are usually spot requirement, which is specific and timely needed.
The overwhelming conceptualizations of intelligence cycle may not be useful, because of massive data.
So we must dwell on the results apart from intelligence cycle.
👉🏾 The interpretation of this:
- the intelligence cycle can also be seen as an information flow on his own.
⟲ AK-1.5.3 Intelligence Duality, dichotomy: context-abstraction
The intellignece frameworks a practical case influncing the abstractions
A nice write up for a specific domain, the information security was noticed (safety):
CTI Key Concepts: A5. The Intelligence Cycle (LI: Nomende C. Security analyst 2024)
The Intelligence Cycle is a six-stage process used by government, and military agencies to produce intelligence.
The six stages are Planning and direction, collection, processing and exploitation, analysis, dissemination and feedback.
The intelligence cycle can be traced back to Sherman Kent, a Yale University history professor.
His journey to intelligence started during World War II, and he was known as the “father of intelligence analysis”.
There are several figures used for the explanation. All six in a cycle and others showing five, in a circle the sixth in the middle.
Another
post (LI: Treston Wheat ) same topic, similar text but:
The cycle, depicted as a closed loop, emphasizes continuous refinement and feedback to ensure that intelligence requirements are met effectively.
👉🏾 When one of the who cycles in the abstractions are a feedback control closed loop, it is acting as a good regulator in the system (system-2 ViSM) for the system.
The intelligence cycle as an information flow with subsystems. :
The delivery of results (which) is connected to a when that is the external to doing the analysis it could by seen as the universe (ViSN).
- system-1 What Planning and Direction, the first stage, involves establishing the goals for an intelligence programme, which includes understanding what needs to be protected, the potential consequences of failing to do so, the intelligence required by the organisation for protection and response, and the prioritisation of what to protect.
- system-3 How The collection stage concerns gathering various types of data and information from numerous internal and external sources. Internal sources are networks and security devices, threat data feeds, interviews, news websites and blogs, social media platforms, websites and forums. Closed sources are ones like dark web forums.
- system-4 Where Processing and exploitation is the stage in which collected data is normalised, structured and organised in a way that can be readily retrieved, searched, and used by analysts.
- system-5 Who The analysis and production focuses on transforming processed information into actionable intelligence. Effective intelligence analysis considers the user of the intelligence and their decisions and is presented in a readily understandable and actionable format.
- system-2 When During the dissemination stage, intelligence is delivered through channels, such as written reports, emails, verbal briefings, or integration with security tools. It is tailored to the needs and technical understanding of the audience.
- universe Which The feedback stage provides information on the future iteration of the cycle. It allows intelligence consumer to report the effectiveness of the intelligence and if it meets their needs.
👉🏾 The confusing en hard parts for understanding in this are:
- The When, dissemination stage, looks to be activities set by a good regulator.
- The consumer for the intelligence cycle is a decision maker in another context, not in the context of this system.
Intelligence frameworks influence at abstractions levels
Practical cases are influencing the mindset how things are functioning by their functionality.
The intelligence cycle for creating / supporting a vision:
- system-1 Context Environment Collection
- system-3 Concept Data Evaluation
- system-4 System Logic Information Analysis
- system-5 Technology Knowledge / Insight Interpretation / sensemaking
- system-2 Components Wisdom sharing Dissemination, decision support
- universe Instance Vision initiation
This mapping shows how Knowledge Insight acts as a pivot point—where feedback, cultural alignment, and strategic foresight converge.
Knowledge / Insight pattern recognition, sensemaking, and foresight synthesis Bridges Wisdom (what we know) with Vision (what we should do) Enables decision relevance, timing, and strategic clarity.
To me surprise a LLM gave this correct answer when in search for the decision maker:
In ZARF, the Instance layer represents the operational manifestation of decisions—not the decision-maker itself.
It’s where behavior is enacted, not where choices are made.
- system-1 Context Strategic framing - Visionary / Architect
- system-3 Concept Hypothesis formation -Strategist / Planner
- system-4 System Logic Decision modeling - Analyst / Regulator
- system-5 Technology Execution logic - Engineer / Implementer
- system-2 Components Integration and composition / Operator / Maintainer
- universe Instance Observable behavior / enactment - Sensor / Actuator / Actor
So, Wisdom is formed at the upper layers (Context–Concept), Insight emerges in System Logic–Technology, and Instance consumes the outcome—but doesn’t originate it.
The intellignece frameworks influencing the abstractions
💡❗ Connecting the "when" and "component" to the good regulator (system-2 ViSM) gives some practical sense to the TOC optimizing flows in being both reactive (Goldrath) and proactive (M. Balle) in the VaSM cycles effecting controlling outcomes.
The consequence is that there are many good-regulators in a system not only one.
Reviewing that for the classic practical example of a car, that looks to be correct.
⟲ AK-1.5.4 Confusing cycles by contexts, abstractions to clear
Information System (IS) and systems thinking a gap for improvements
In pursuit of systems theories for describing and analyzing systems in organizations (researchgate: Twenty-Sixth European Conference on Information Systems (ECIS2018), Alter, Steven 2018)
Goal: a path forward by which the IS discipline might pursue systems theories in order to understand IS in new ways, generate innovative and useful systems theories, and achieve more impact in the world. ...
(5.1)
WST is much less useful for analyzing an entire large enterprise, such as Toyota Motors or the British Government, whose thousands of participants perform thousands of activities that are not linked directly. ....
The WSF (Work system framework) identifies and organizes by nine elements of even a basic understanding a work system’s form, function, and environment during a period when it is relatively stable.
...
Work system life cycle model. The WSLC represents the iterative process by which work systems evolve over time through a combination of planned change (formal projects) and unplanned (emergent) change via adaptations and workarounds. ...
Implementation refers to implementation in the organization, not implementation of algorithms on computers.
A full iteration from one operation and maintenance phase to the next might be viewed as a transition from a previous version of the work system to a subsequent version.
It is a not very hopeful description of the state of Information Systems where the association to systems theory is broken. Those nine elements could be connected to ZARF.
The system flown in a practical lens for a system as a whole
The operational value stream in a Pull and Push in all steps looks complex but is simple when understood.
The duality and dichotomies in applying systems thinking is a change in perspective.
A narrative in attempt escaping confusing anatomy and physiology details.
AK-1.6 Learning systems maturity from 6x6 RFW's
The perspective of what is seen is an uncertainty on his own.
The choices by chosen scopes by the consumer, actor, stakeholder, is an unpredictability.
There are learning points
- Systemic failures in systems by distractions do exist. Distractions that adjust the purpose behind understanding systems into avoiding adaption.
- Simple distractors are caused by wanting adaption but missing how to adapt those in the system.
- Using the intelligence cycle as a subsystem in the system.
- Out of the crisis using smart systems supporting the systems.
The space for values, knowledge, structure, and tradition is limiting the scope.
There is a exception in the mindset to the other components.
The reflections in perspectives in systems are the good regulators at the journeys.
⟲ AK-1.6.1 Evaluating the pattern of four layers, the 3D model
How the idea for the 3D model got started
Thinking on devops, portfolio management, budgeting by information systems, the evolvement was:
- A partial understanding of value stream modelling abbreviated as VaSM to avoid confusion.
It is about the operations context in functioning for the product/service in the full Pull Push cycle for the product/service.
⚠ Confusing and distracting: using the word products for components, the product/service it is not about isolated components.
👁 An imaginary floorplan for the activities of the VaSM to visualize.
- Changing, shaping the VaSM is what development is about.
It follows the same paths as the VaSM but the focus in not on the functioning but the functionality of the product/service.
The context approach and mindset for involved people is very different to that of the operations.
A full cycle is four aspects, a pattern that is popping up every time::
- Gathering ideas, proposal for products/services (backlog),
- Selecting & prioritizing from the backlog,
- Realisation of what was demanded in building and verification.
- Accepting the innovation, changes together with well documented specifications.
👁 An imaginary floorplan for the activities of Development & operations connections to visualize.
- For the safety, cyber security, aspect it is not part of VaSM.
The question where is does belong, brought it to actual realisations the instances by operations and the rules corporate ethos.
This is where the viable system theory entered, abbreviated as ViSM to avoid confusion.
A Secure Information Management Framework (SIMF)
👁 Two imaginary floorplans for the instances by operations and the execution in command & control to visualize.
These have unpredictable interactions by the universe.
⚠ Reviewing this I became aware the adaption for change as a whole (system-4 ViSM) and the ethos atmosphere (system-5 ViSM) are missing.
There is no logical hierarchy between development, operations VaSM and the operational instances, they are acting independent although there are tight relationships.
The classic four dualities, a pattern that is popping up every time:
- Engineering - Machines, technology instances by operations
- Administration - Processes value stream modelling - operations, development
- Delivery- People execution in command & control
- Supply - Structure adaption for change, ethos atmosphere
- Regulating, controlling flows is by a feed-back loops adapting for what is seen as problems to solve (system-2).
This part is what gets much attention ins ViSM but is in its fundaments distracted by the hierarchical leadership control setting in human values.
The steep learning path for understanding Zarf is simplified by following a similar path.
VaSM, ViSM, SIMF perspectives in a 3D model
Each of the floorplans got a fractal content for better understanding what it is about.
Stakcing them vertical with the change by time increasing for wat is done in the know resulted in a 3D objects with 4 layers.
This is about the anatomy and phusilogy of the system.
The projection what is seen changing from floor-plans to side-views following the flow of VaSM at that floorplan for different perspectives in interactions.
In a video (interactive cube) showing aside the stacked floorplans also the DevOps and PortfolioPlan relationships:
The maturity of the four stacked floorplans
Each cell at the four layers got indicative and an visualisation that are reflecting the words and concepts used informations systems.
This should help in the understanding but changes for dedicated disciplines and changes by culture are to be expected.
The result in practical cases should be the proof of maturity in what is chosen now.
The maturity of applying Jabes the realisation using ZARF is part of the Jabes proposal. (I-Jabes ../design_meta/design_meta.html).
A primary evaluation of the four stacked floorplans
Stacking the floorplans is changing the perspectives in meaning.
- For the understanding in expectations there is an increasing window in time.
Even in the change from the VaSM flow to the operational instantion that is changing but the time-Window has become that small it is not felt relevant by human values.
- For an increased time-window it is about functionality for the fucntioning in the direct related smaller time-window.
- The Zachman 6*6 reference frame is using 6 abstraction levels. The time-window in concept * context and the time-window in system logic - technolog physics (architect - engineer) are not felt relevant.
The levels are consolidated into execution in command & control and development.
- ⚠ There is a distractor by human values in the context Honour and/or fame.
Having power over others in the setting of doing functionality were other have to follow in functioing is a hierachical approach.
This kind of power is felt as of more value. In an objective evaluation that kind of valuation is seen as negative for the system.
This is a start of neurology and sociology for the system.
⟲ AK-1.6.2 Systemic distractors in systems causing failures
The unknown impact of balancing generic human values
The four human values are simple but have no scale in good and bad and no measurements.
The only value that has a scale for measrurement is an ammount by money at a moment in time.
➡ Human values by appearances:
- Safety This a short term important value for surving in the universe this embeds shelter food hygiene and social contacts.
- Wealth For the long-term not having challenges in surviving is wealth extending to luxuary, power over others and cultural contact.
➡ Values of the human spirit.
- Fame Is the the state of being known or talked about by many people, especially on account of notable achievements.
- Honour Is a quality that combines respect, being proud and honesty.
There are frictions with morality because morality is adding subjective value in bad vs good.
Not having scales in bad/good and measuremnents is a disturbig question in morality, ethics.
Experiments in this area by their nature questionable by ethics.
Ignoring what those drivers have for effects is also questionable.
Aside what history can learn about this, there some experiments done.
🕳
Universe 25, John Calhoun famous mouse-behavior experiment, February 1970.
He supplied for full safety in short-terms but nothing of the othervalues.
The results did repeat many times in the same way by a full collapse of the community as system.
🕳
Milgram experiment
He supplied for safety for the teacher and offer honour in the results for actions.
The results did repeat many times in the same way by a activities that were seen as not ethical, the opposite of the promise and the personal idea of actor.
Distractors for failures in by hypes, buzzwords
🕳 Acronyms the fast food gravity for uncertaintity.
From a linkedin discussion the weirdness effects in the world of buzz.
VUCA, BANI and RUPT: rapid, unpredictable, paradoxical, tangled, TUNA: turbulent, uncertain, novel, ambiguous.
ViBRanT a cool acronym for marketing: ViBRanT = dynamic, lively, pulsating, swinging.
Every few years a new alphabet soup is cooked but Complexity cannot be reduced to four letters.
Those who want to understand should stop collecting acronyms and start studying complexity, thinking about it, and applying it in practice.
Acronyms are fast food for thinking, quickly consumed but without nutritional value.
Complexity is slow food; it requires time, attention, and discussion, but it truly satisfies.
😲
This jumping to buzz word in branding, marketing is a market on his own.
It is felt as personal honour, giving personal wealth by their activities but is not helping the system as a whole, but it is a hampering factor.
🕳 Acronyms the fast food for process cycles
Unfortunately, that's not the only thing that's happening with a multitude of acronyms like
PDCA,
DMAIC,
ADKAR,
OODA,
ADDIE (Analyze - Design - Develop - Implement - Evaluate) ,
SCARF (Status - Certainty - Autonomy - Relatedness - Fairness),
SOAR (Strengths - Opportunities - Aspirations - Results),
AGIL (Adaptation - Goal attainment - Integration - Latency) and many more.
The similarities in these frameworks:
- Structured stages: Each model breaks down complex change into manageable steps.
- Feedback loops: Most include evaluation or reflection phases to refine the process.
- Cross-disciplinary use: are used in business, tech, healthcare, education, and more.
- Scalability: can be applied at individual, team, or organizational levels.
How is it possible to reduce those to something simple and universal?
😲
The jumping to acronyms is food for branding buzzwords, creating a market on his own.
The signals are certifications for a acronym, just name some: Safe, Itil, Togaf, (supplier)-certified, those for Safety cybersecurity.
It is felt as personal honour, giving personal wealth by their activities but is not helping the system as a whole, but it is a hampering factor..
A view of system thinking on systems
There is a difference in thinking of systems a model of real situation and thinking on systems how it goes in systems thinking.
This is a step into abstraction generalizing how systems behave.
general system theory principles (Graham Berrisford 2025)
Ludwig von Bertalanffy was an Austrian-born biologist and philosopher, widely recognized as the principal founder of General Systems Theory (GST).
In the middle of the 20th century, Bertalanffy set out to develop a GST by identifying system concepts and principles shared by different sciences.
For example, many feature the concept of a system in which components/parts interact - in some regular or repeatable way - to produce some emergent effect(s) of value or interest.
Bear in mind that general system theorists look for where different sciences share the same concept, not just the same word.
Words such as "information" and "organization" are used with different meanings by different systems thinkers.
Soft Systems Theory
SST is about “organizations”, meaning human institutions and businesses with a management structure and organized activities, in which humans act in defined roles.
Soft systems thinkers' ideas (Graham Berrisford 2024)
In the 1950s and 60s, some sociological thinkers became aware of two major developments in system science - general system theory and cybernetics - and wrestled with how to apply to system theory to what was called "management science" and might now be called "organization theory".
Systems Thinking Foundations (Graham Berrisford 2025)
An interesting disturbing statement at 45:38
Has the time come to rescue system thinking from:
- Organisation theory about how to manage and motivate employees?
- Opinions about how people do or should behave in organisations and other communities?
😱
It states the the distraction into organisation, is a root-cause that systems thinking is failing.
Evaluating that statement is looks to be correct.
- Strategic Alignment s J. C. Henderson, N. Venkatraman (IBM Systems Journal 1993).
Intention how to understand & manage interactions in system hijacked by organisation theory.
- the nine plane AIM Amsterdam information model, hijacked by organisation theory.
- Viable systems theory overwhelmed in organisation theory.
- Zachman, distracted into organisation theory, Enterprise Architecture.
- Lean Agile and others the same in hierarchical power: resistant to change.
To solve, rescue from: the hierarchical approach by the bad human value in power over others.
⟲ AK-1.6.3 Vision Wisdom Knowledge into knowledge management
Knowlegde management, a fundament in Policies, policymakes.
The question for documenting and sharing knowledge in a more practical way is generic.
When creating and defining policies it is that what the basics are is about. Got a signal for looking at a research in that.
It is case study by observing what and how it is done, there is no attempt to align that to any scientific theory.
Communities of Practice Playbook CoP (EU JRC july 2020)
that is associated with a short (100 pages) handbook
Science Communities of Practice Playbook light
(4.1 page 99)
In this regard, knowledge assets are the fundamental elements of the community’s knowledge pool.
They are the artefacts of all the tacit and explicit knowledge present within and around the community.
For example, this knowledge can be unstructured and personal (e.g. individual expertise and skills) or structured and codified (e.g. guidelines and regulations).
The more these assets are made explicit and structured, namely codified or made reliably accessible over time, the easier it is to share and engage members in using and adding to that knowledge and its various sources.
By not making prior or implicit assumptions (or taking contextual knowledge for granted), but instead clearly stating any assumptions and contextual knowledge, it is easier for others to access this knowledge pool.
In a figure:
see right side.
The circle is promoted by 4 stages Drive, Steer, Build, Manage but each of those shows two artic acts with two others.
The total of artifact is 3+3 for each.
A misinterpretation is a focus only on those 16 artifacts at the outer ring.
Knowledgemangement for a variety in purposes
The "CoP Playbook" is a good case study for organizing the organisation using knowledge in Wisdom using Zarf and Jabes.
Although nowhere Zachman is mentioned there is a remarkable similarity by 4 disciples Steer Build Manage Drive and 6 levels in indetifications (context).
It is a complete cycle and not only that of engineering as in the Zachman EA.
In that detailed case study to get done in floolowing chapters the attention points in observable practices, metrics and roles to get into those details.
⟲ AK-1.6.4 Smart systems, out of the information systems crisis
a n the A primary evaluation of the four stacked floorplans
The intelligence cycle is a revitalisation of DIKW making it usable for:
- Research analyses of a problem of unknown situations, building op knowledge wisdom vision
- Applying vision wisdom knowledge to situations that are known or assumed known by similar patterns.
- Usage in system dynamics, good regulators that are controlling systems.
The data gathering part and transforming that to information is getting support by machines, LLM.
That change is an important change for knowledge management.
A smart system, eg a LLM, helping in understanding and duplication in patterns
Having the content in a website format hard work to create but easy access for a LLM.
Not all is automagically processed, figures were additional uploaded for a analyses.
That kind of analyses is far more demanding used selectivley.
😉 The following pages in a LLM, 💰
Please analsye deeply:
- ../design_bianl/bianl_6x6systemslean.html Sys6x6Lean defines ZARF, part of Jabes.
- ../design_bianl/design_bianl.html C-Shape shaping narrative theory (C-Shape).
- ../devops_bianl/devops_bianl.html r-shape narrative for shaping practices.
Important building block: USM (Unified Service Management metohodology.
- ../design_meta/design_meta.html I-Jabes the theory for a practical tool.
- ../devops_data/devops_data.html r-6icsr narrative practices for how Zarf extends viable systems, used abbrevations VSM and ViSM, by "VSMB_SYST_* rules and in Safety for SIMF_*-* (I-C6isr).
- ../devops_math/devops_math.html r-know practices in search for relationship in a setting of cyber floorplan models with involvement of value streams.
The following figures are asked to be analysed by upoading:
- dim4_6w1h.jpg (AK-1.3.1) basic 6*6 approach by engineering, administration, supply, delivery
- Belbin-Team-9areas.jpg (A-2.5.1) classic static operational belbin roles
- Belbin-Adapt-9areas.jpg (A-2.5.2) adjusted to systemic adaptive belbin roles
- dim4_6w1h.jpg (AK-1.3.1) basic 6*6 approach: engineering, administration, supply, delivery
- Jabes_Zarf_wheel.jpg (A-2.5.4) adjusted to systemic adaptive belbin roles
- Communities-of-practice-success-wheel.png (AK-1.6.3) Similar approach as Jabes Zarf wheel, different words, another oriëntation (135 grd).
Hint: Manage=Administartion, Build=engineering, Steer=Supply, Drive=Deliviery
- Jabes_product.jpg Found e.g. in C-Shape, discribes the functional Jabes orchestration.
The hint in this: I=Input R=Result A=Actions, Activity S=Steer
- Jabes_process.jpg Found e.g. in C-Shape, discribes technical Jabes orchestration.
✅ The result is a reinforced learning loop. Adjusting content and asking to updated the analyses by the LLM, resulting in adjusting the content.
Using examples ad hints gave good responses for a desired outcome.
A smart system, Jabes, supporting the knowledge work effectively
Traditional reference models (like Zachman) lacked the depth to handle human values, systemic tensions, and adaptive governance.
👉🏾 From these gaps, ZARF (part of Jabes) emerged—not as a patch, but as a reframe.
- It layered anatomy, physiology, neurology, and sociology into a living system.
- It replaced “Why” with “Which,” enabling recursive decision modeling.
- It added time slices, feedback loops, and trust boundaries.
- It gave systems a face, a voice, and a conscience.
The sections diagnose what was missing.
| The tradional gaps | Tadional gaps | Converage |
| Human Motivation | No modeling of safety, honor, fame, or trust | ZARF_XPOS (Sociology) |
| Legitimacy & Feedback | No feedback-based trust or social adaptation | ZARF_VIRU + ZARF_XPOS |
| Uncertainty Handling | No fuzzy logic or refutation criteria | ZARF_VIRU (Neurology) |
| Systemic Dualities | No modeling of internal/external tensions | ZARF_STRC + ZARF_INTR |
| Governance Complexity | No unified taxonomy of rules and constraints | ZARF_VIRU |
| Cultural Adaptation | No support for evolving social norms | ZARF_XPOS |
| Time Sensitivity | No phased transformation logic | ZARF_STRC + ZARF_VIRU |
✅ The approach of putting the content itself in 6*^6 reference frame consistently for knowledge work is the idea of Jabes.
There are no applications-tools available for that. Making those available and adding standard meta reference frames is the innovative idea.
👉🏾 Jabes is a frame work and a proposal for a technical tool.
That is not a tool in the sense of some guidelines (Leadership toolbox, Scrum toolbox) but a technical practice in line with SAP for ERP DB2 for a DBMS to store data.
That tool has the goals of:
- A support of Zarf and Jabes framework in categorizing and managing knowledge.
- A simple holistic way of storing and communicating knowledge for all stakeholders.
- Evaluating the quality of all the knowledge that is structured organized stored in relevancy by maturity levels in an associated quality framework (CMM-0 - CMM-5).
AK-2 Details systems ZARF tactical 6x6 reference framework
AK-2.1 Enabling the understanding continuum
Understanding systems and changing systems are several levels of abstraction.
The vocabulary used for the understanding is the fundament for what follows.
Using other word than what is usual can cause confusing but also avoiding confusing in the need of unlearning what causes confusing.
Challenges for the Enterprise concepts:
- Concepts: identification, taxonomy, owners, lifecycle
- Domain: I (Influence) & A (Adaption)
governance shapings how artifacts travel across design to operate.
- Owner: Metadata Steward, Board Governance + Architecture Board
⟲ AK-2.1.1 Information semantics for concepts in abstractions
Master data for semantic anchors
Master data are not merely static reference entities, but they serve as semantic anchors within the ZARF multidimensional grid, supporting clarity, traceability, and transformation across abstraction layers and interrogative flows.
⏳ Master data:
- defines the semantic boundaries for valid transformations, semantic contract between roles and systems.
E.g. only certain roles can trigger specific actions.
- information inherits and propagates governance constraints, a recursion anchor for “Which” decisions at every abstraction level.
E.g. naming conventions, data quality rules.
- encodes dependency logic, boundary object across flows (engineering, administration, delivery, supply).
E.g. a product must exist before it can be priced or sold.
- shapes external identity and trust, a legitimacy enabler, aligning internal structure with external expectations (safety, wealth, fame, honor).
E.g. how a system presents its catalog, roles, or services to the outside world.
Master data is not just "data about things" it is also about relationships and interactions.
Less abstract:
| 6w1h | Master data role | Example |
| What: | Entity definitions (nouns) | Product, Customer, Asset. |
| How: | Classification schemes, taxonomies | Product categories, Risk levels. |
| Where: | Location hierarchies, jurisdiction zones | Warehouse codes, Legal entities. |
| Who: | Role definitions, organizational units | Constructor, Validator - Stakeholders. |
| When: | Temporal anchors, lifecycle states | Reference in Valid-from dates, Maturity stages. |
| Which: | Decision criteria, disambiguation logic | Product eligibility rules, Role-task mappings. |
Each of these is instantiated across abstraction layers—from conceptual (e.g. stakeholder roles) to operational (e.g. user accounts, cost centers).
⌛ Example for a role within master data business language:
- Domain - Master Data: Role = "Data administration - Validator".
An alternative title could be "Data Steward".
- Semantic Function : Ensures semantic integrity of transformations for all products/services using the same artifacts.
- Governance: Must be assigned before a "Which/Why" decision in Business language understancing is finalized.
- Interaction: Feeds into domains:
- “Master Data - When”: for agreed aligned decisions using diplomacy.
- "System Logic - How": task design, flow design for functionality.
- “Technology - What”: access rights by platforms.
💣 Without a shared language it results into: volatility & confusion
The business rules and data semantics concepts
Ronald G. Ross, a leading authority on business rules and data semantics, outlines six fundamental kinds of data descriptions in his work to help organizations achieve clarity and precision in business communication. These descriptions are essential for creating concept models that align data with business meaning.
A need for limiting the scope in meaning:
- A "concept model": model of concepts, based on the vocabulary used to represent them.
- The word "conceptual model" could be imagined to be used for explainations in domains.
⏳ A "model of concepts" is a structured semantic framework that organizes abstract ideas, roles, and relationships into coherent, actionable patterns.
It serves as a cognitive scaffold for understanding, communicating, and transforming complex systems across domains.
Core Characteristics:
- Semantic Integrity: Ensures each concept is uniquely defined, contextually grounded, and recursively traceable.
- Multi-Perspective Alignment: Supports diverse viewpoints (e.g., engineering, administration, delivery, supply) through ordered interrogatives (What, How, Where, Who, When, Which).
- Fractal Recursion: Enables zoom-in/zoom-out navigation across layers of abstraction, maintaining consistency across scales.
- Role-Flow Mapping: Embeds constructor, validator, and other agentic roles to clarify responsibilities and decision logic.
- Temporal Awareness: Integrates Now, Near Future, and Far Future slices to support adaptive governance and scenario planning.
The functional Purpose is: To disambiguate meaning across disciplines and domains, enable transformation by linking abstract concepts to concrete implementations, support evaluation through meta-criteria, feedback loops, and maturity models and to To bridge human values and technical rigor, aligning systemic drivers with stakeholder relevance.
⌛ Think of the model of concepts as the grammar of meaning, and the conceptual model as the story told using that grammar.
How they are connected in their differences:
| Context | Model of Concepts | Conceptual Model |
| 🔰Purpose: | To define and organize abstract concepts, roles, and relationships semantically | To represent how a system works or should work at a high level. |
| 🔰Focus: | Semantic clarity, typology, and meaning | Functional structure, behavior, and system logic. |
| 🔰Structure: | Often recursive, fractal, and multi-perspective | Typically hierarchical or flow-based. |
| 🔰Usage: | Used for meta-modeling, ontology design, and semantic alignment | Used for system design, stakeholder communication, and early-stage architecture. |
| 📚Artifacts: | Concept matrices, role typologies, interrogative maps (e.g., ZARF layers) | Entity-relationship diagrams, flowcharts, UML class diagrams. |
| 📚Temporal: | Explicitly includes Now/Near/Far Future slices for adaptive governance | Often static or time-agnostic unless extended. |
| 📚Roles: | Constructor, Validator, Observer, etc., embedded for semantic symmetry | May include actors or agents, but not semantically formalized. |
| 📚Philosophy: | Bridges epistemology, ontology, and systemic ethics | Focuses on operational feasibility and stakeholder alignment. |
The "business rules" and data semantics practices
Mapping of business language and model of concepts to make it more practical.
The Six Kinds of Data Descriptions:
- Defining Things
- Providing precise definitions that reflect business intent.
- Goes beyond dictionary meanings to capture contextual relevance.
- Categorizations
- Assigning things to categories based on business rules or logic.
- Often used for decision-making, reporting, and compliance.
- Classifications
- Grouping things based on shared characteristics.
- Supports structured thinking and data organization.
- Naming Things
- Assigning consistent and meaningful names to concepts.
- Crucial for shared understanding and avoiding ambiguity.
- Disambiguating Things
- Resolving confusion when terms have multiple meanings.
- Ensures that stakeholders interpret terms consistently.
- Distinguishing Things
- Identifying what makes one concept or item different from another.
- Helps clarify boundaries between similar terms or entities.
These descriptions are part of Ross’s broader methodology for building concept models, which serve as blueprints for aligning business vocabulary with data structures.
The
brsolutions is limited in access, an open standard:
Semantics Of Business Vocabulary And Business Rules .
⏳
Mapping of business rules concepts into a 6*6 reference.
The 6w1h-axis is the flow for achieving distinguished well understandable meaning.
| Semantic | 6w1h | Zarf | description |
| Definition | What: | Defining Things | Clarifies the essence of a concept—what it is. |
| Category | How: | Categorizations | Explains how things are grouped or used based on business logic. |
| Class | Where: | Classifications | Often relates to where things belong within a taxonomy or structure. |
| Identity | Who: | Naming Things | Assigns identity—who or what is being referred to. |
| Timing | When: | (-void-) | Ross’s framework doesn’t explicitly address temporal aspects, but Verb Concepts (from his broader model) can help express timing or events. |
| Distinctive | Which: | Distinguishing & Disambiguating | Helps choose between alternatives and clarify which meaning applies. |
This is a guidance for when you're building a concept model or trying to improve data quality, asking the right questions like:
- "What is this?"
- "Which type does it belong to?"
- "How is it defined?"
This still very abstract, too difficult to grasp.
⌛ Example:
Applying business rules for descriptions in the context of "Customer Interaction" concept modeling:
| Zarf | Context in Concepts for getting details |
| Definition: | what a “customer interaction” is. E.g., a touchpoint involving communication between a customer and service agent. |
| Category: | Interactions by channel. E.g. email, phone, chat or whatever for the intent in the interaction (support, complaint, inquiry), or urgency. |
| Class: | Interactions by location. E.g., in-store, online, mobile app. This supports geo-tagging or regional analysis. |
| Identity: | Name entities: customer, agent, system. Assign identifiers like customer ID, agent ID. |
| Timing: | Record rimestamps, to track sequences. E.g., “Customer called at 10:15 AM, ticket resolved at 2:30 PM.” |
| Distinctive: | For similar interactions. E.g., complaint from a feedback to differentiate or disambiguate “support” when it could mean technical help or billing inquiry. |
⟲ AK-2.1.2 Concept: Stakeholders - roles and tasks scope visions
Mapping of abstraction semantic for using BRules
The abstraction-axis is how the meaning is perceived by another perspective in the involved tasks.
The combination of both axis context and abstraction should cover a specific discipline.
For disciplines related to the IS (Information Systems) domain going into more details, the are:
- Stakeholders - roles and tasks (People)
Note: there is no hierarchical mapping intention.
- Portfolio - budget(Processes)
Note: this is the antipode of DevOps, they are the duality in enabling value streams.
| ViSM | Semantic | 👐 | Stakeholder Role/Task | 👐 | Portfolio budget |
| universe | Context | | Role | | Initiative |
| system-5 | Concept | | Decisions | | Budget Item |
| system-4 | System Logic | | Influence | | Resource |
| system-3 | Technology | | Engagement | | Constraint |
| system-2 | Components | | Feedback | | Outcome |
| system-1 | Instance | | Legitimacy | | Scenarios |
Stakeholder Alignment Matrix: Semantic Mapping
Questions that help structure stakeholder understanding in enabling role clarity, decision traceability, and governance alignment across context layers.
Simple questions:
| ViSM     | 6w1h | 👐 | Zarf | Stakeholder role alignment focus |
| system-1 | What | | Definition | What is the stakeholder’s role and purpose? |
| system-3 | How | | Category | How does the stakeholder operate or influence the system? |
| system-4 | Where | | Class | Where does the stakeholder act within the system landscape? |
| system-5 | Who | | Identity | Who embodies this role in real-world or meta-agent terms? |
| system-2 | When | | Timing | When is the stakeholder active or expected to intervene? |
| universe | Which | | Distinctive | Which decisions, domains, or responsibilities for influence ownership? |
Novice Questions:
Definition Master vocabulary language:
- Stakeholder role types (e.g., sponsor, servant, decision-maker).
- Clarify what each role is and is not.
- External practices that are influencing (CoP)
- Key elements to building trust and guaranteeing a safe place (CoP)
|
Category Structure by:
- Stakeholders by influence, decision rights
- Stakeholders by Engagement level (e.g., RACI, SIAR)
- Roles working together in taking decisions and act on them (CoP)
- Roles working practices and processes fitting needs, purpose, and value (CoP)
|
Class Geography in:
- Stakeholders by domain (e.g., strategic, operational, external/internal)
- Clarifification of stakeholders by planes or layers
- Stakeholders by Channels that connect external demand (CoP)
- Stakeholders by Purpose raison d'être in support of the vision (CoP)
|
Identity Knowledge in who is who:
- Names using identifiers to roles, link to real-world actors or meta-agents.
- Clarify persona indepently but communicate them together. (RBAC)
- Define the membership and the surrounding ecosystem. (CoP)
- The actors involved in/or impacted (CoP)
|
Timing Impact visible to stakeholders:
- When stakeholders act—decision timing
- Clarify escalation paths, lifecycle involvement.
- SMART steps, behaviours and rituals. (CoP)
- strategy to reach your community vision (CoP)
|
Distinctive Unambiguous in:
- Clearity in overlapping roles (e.g., “architect” vs “designer”)
- Clarify disambiguate responsibilities in complex systems.
- The challenge to address / the problem to solve (CoP)
- Legitimacy, the demand or need, long-term goal (CoP)
|
Stakeholder Alignment 6*6 Matrix: Semantic Mapping
Questions to structure: Stakeholder understanding across context & abstraction layers.
❶ Alignment by What en How:
| What (define) | How (Categorize) |
| Role | What is the role’s purpose? | How is it grouped: strategic/tactical/operational? |
| Decsions | What decisions are made? | How are decisions structured? |
| Influence | What influence does the role exert? | How is influence measured or expressed? |
| Engagement | What kind of engagement is expected? | How is engagement categorized: consult/inform? |
| Feedback | What feedback is expected or given? | How is feedback structured (loop type)? |
| Legitimacy | What legitimizes the role? | How is legitimacy earned or maintained? |
❷ Alignment by Where en Who:
| Where (Classify) | Who (Identity Name) |
| Role | Where does it operate:<domain/layer>? | Who holds this role: persona/agent? |
| Decsions | Where are decisions applied? | Who makes the decision? |
| Influence | Where does influence manifest? | Who is influenced or influencing? |
| Engagement | Where does engagement occur <channel>? | Who engages with whom? |
| Feedback | Where is feedback routed? | Who gives/receives feedback? |
| Legitimacy | Where is legitimacy recognized? | Who grants legitimacy? |
❸ Alignment by When en Which:
| When (Time) | Which (Distinguish) |
| Role | When is the role active (lifecycle)? | Which roles are similar/conflicting? |
| Decsions | When is it made? | Which decision paths exist? |
| Influence | When does influence peak or fade? | Which influences are dominant or latent? |
| Engagement | When is engagement triggered? | Which engagements are critical or optional? |
| Feedback | When is feedback collected? | Which feedback loops are closed/open? |
| Legitimacy | When is legitimacy reviewed or challenged? | Which legitimacy sources are trusted? |
⟲ AK-2.1.3 Information semantics for purposes, goals methodologies
The yin-yang dance between making and taking.
Dualities in
value creation (M.Balle 2025) is a ethical challenge.
⏳
The issue in this to change:
In a traditional supply chain the deal is to put as much pressure on price as you can and let suppliers solve their problems on their own.
👉🏾
It's a challenge to see both sides clearly. On the “making” side, you have to be curious about how value is actually produced step by step — how products are designed, how services are delivered, where quality comes from.
On the “taking” side, you have to understand the negotiations and power games between your stakeholders — what you pay, what you charge, what contracts and incentives you set.
- The first is making. That’s when a company invents, builds or delivers something people actually want, and gets paid because customers see its usefulness.
- The second is taking. That’s when a company doesn’t so much build more usefulness as squeeze more out of the system — by paying suppliers less, shifting risk to staff, locking in customers, aggressively pursuing financial shenanigans or capturing subsidies and tax breaks.
No real business is purely one or the other. Over time every organisation develops a mix. If it leans too far into taking, it hollows itself out: staff disengage, suppliers cut corners, customers leave, and the whole thing starts to implode. If it leans too far into making, it may delight customers but burn through cash, become unattractive to investors, and struggle to fund its future. ...
👉🏾 Power can be use both for the making, the plowing, the sowing, the growing and the taking, the reaping.
The point of hashtag#Lean is to make making less wasteful, not to increase taking.
States in the internal purpose line: culture in the now, an example for leaders applying the lean mindset:
Excellence Isn't an Accident (Li - LEI James Morgan 2025)
If you want to create world class products, first you must develop world-class people.
That isn't an accident. It is the result of a culture of discipline, craftsmanship, and the pursuit of mastery at every level of the organization.
⌛ “Great leaders don’t just deliver results—they ensure the next generation can deliver even better results.”
Lean Product & Process Development Guiding Principles At-A-Glance (LEI James Morgan 2020)
- What 👁 Putting People First: Organizing your development system and using lean practices to support people to reach their full potential and perform their best sets up your organization to develop great products and services your customers will love.
- How 👁 Understanding before Executing: Taking the time to understand your customers and their context while exploring and experimenting to develop knowledge helps you discover better solutions that meet your customers needs.
- Where 👁 Developing Products Is a Team Sport: Leveraging a deliberate process and supporting practices to engage team members across the enterprise from initial ideas to delivery ensures that you maximize value creation.
- Who 👁 Synchronizing Workflows: Organizing and managing the work concurrently to maximize the utility of incomplete yet stable data enables you to achieve flow across the enterprise and reduce time to market.
- When 👁 Building in Learning and Knowledge reuse: Creating a development system that encourages rapid learning, reuses existing knowledge, and captures new knowledge to make it easier to use in the future helps you build a long-term competitive advantage.
- Which 👁 Designing the Value Stream: Making trade-offs and decisions throughout the development cycle through a lens of what best supports the success of the future delivery value stream will improve its operational performance.
The LPPD Guiding Principles provide a holistic framework for effective and efficient product and service development, enabling you to achieve your development goals.
The concepts of stakeholders, people or legal entities.
Stakeholder management isn't a peripheral task, it's a core architectural concern, recognizing that architecture must serve, influence, and be influenced by people who hold varied agendas, authority levels, and attention spans.
Power isn’t about job titles. Influence can come from tenure, informal networks, or control over budgets and timelines. Interest isn’t fixed. A stakeholder uninterested today may become highly engaged once real-world impact emerges.
👉🏾 How to define stakeholder identification and classification?
⏳
Stakeholders are modeled as conceptual agents with roles and influence vectors.
Each stakeholder becomes a master data entity with joint attributes:
- ID: <discipline>:Product-Service_www: <short description>
- Temporal: <time window active>
- ID: <discipline>:StakeHolder<:S/I/A/R-M/E/V/C>:_xxx
Situational, Identification, Alignment, Realisation
- Type Role: (1*) change/run/governance/external: <Constructor, Validator, Inventor, Trickster, Diplomat, ..., Specialists, Implementer, Coordinator, ... , Board, ... , Observer, Influencer, Customer, Regulator, ... >
- Domain: <Business, Technical, Governance, Cultural>
- Temporal: <time window active>
- ID: Influence_zzz
- Temporal Relevance <project phase sensitivity>
- Semantic Reach <cross-layer resonance >
- Influence Score <(decision impact 0-10 >
- Interest Score <engagement level 0-10 >
- Impact Score <engagement level 0-10 >
- ID: Person_yyy <name reference identifier >
- Temporal: <time window active>
Stakeholders have concerns that can propagate into requirements that get realised in validations to get specifications.
👉🏾 Concerns are modeled as interrogative-linked concept records by issues , e.g.:
- “What are the risks to data integrity?”
- “Why is this role excluded from validation?”
- "There is a data retention policy misalignment"
- "Convinced in Lack of visibility by dashboards"
⌛ The concerns, suggestions, backlog items:
- ID: <discipline>:Product-Service_www:ConcernsI_qqqqqq
- Origin-S: ➡ <discipline>:Product-Service_www:StakeHolder_I/A/R/S_xxx
- Origin-P: ➡ Influence_zzz:Person_yyy
- Temporal: < time window for origin relevance>
- ID: <discipline>:Product-Service_www:ConcernsI_qqqqqq:ConcernsD_rrr
- Abstract: <Concept,Context,Logic,Physical,Component,Instance> When not cleared up consolidated indicators Strategy, Tactical, Operational or Business, Technology
- Issue_sss 1*: < Affected Contructs>
- ClosedLoop 1*: < Feedback & regulator update moments)
- Temporal: <time window for concern relevance>
- Status_ttt 1*: < progress and resolutions status> (by update moments)
- 0* Related-S:Product-Service_www:SpecsI_?:SpecsD_?
<short argument - reason change of specs >
- Temporal: <time window for concern relevance>
- 0* Related-C:<discipline>:Product-Service_?:ConcernsI_?:ConcernsD_?
<short argument - reason concern to add on that >
- Temporal: <time window for concern relevance>
- 0* Followd-C:<discipline>:Product-Service_?:ConcernsI_?:ConcernsD_?
<short argument - reason concern follow up on this one>
- Temporal: <time window for concern relevance>
This can be indexed, visualized, and cross-linked in semantic dashboards using a relational storage system.
Traceability auditability of the process by the suggestions, concerns, backlog is achieved by the documenting in knowledge in relationships.
A data model for managing knowledge for systems, Jabes.
👐 The governance of stakeholders, budgets is Volatile, Uncertain, Complex and Ambigious.
| influence | interest | impact | Engagement |
| High | High | High | Co-create & consult |
| High | High | Low |
| High | Low | High | Satisfy & inform |
| High | Low | Low |
| Low | High | High | Inform & align |
| Low | High | Low |
| Low | Low | High | Monitor passively |
| Low | Low | Low |
See right side.
Not all stakeholder are treated equally.
For all kind of activities the interactions to stakeholders classified using a dual-axis matrix.
💣 A classic project manager is biased to have influence an interest getting aligned caused by hierarchical lines that affect his personal rewards.
There are likely many more aspects than that of the project manager.
How the Stakeholders are managed and how the budget/plan is governed is left open.
A way out of this dilemma is have the CEO being accountability responsibility in delegating this kind of work.
⟲ AK-2.1.4 Concept: Portfolio - budget (Processes) goal visions
Portfolio d planning Compass
Questions that help structure Portfolio - budget understanding across context layers.
A financial budget is just a constraint for the planning among other constraints, however the budget is the leading when finance is the main driver.
Simple questions:
| ViSM     | 6w1h | 👐 | Zarf | Portfolio - plan alignment focus |
| system-1 | What | | Definition | What is being budgeted or funded? |
| system-3 | How | | Category | How is the budget structured and allocated? |
| system-4 | Where | | Class | Where is the budget applied within the DevOps landscape? |
| system-5 | Who | | Identity | Who owns, approves, or consumes the budget? |
| system-2 | When | | Timing | When is the budget planned, committed, or reviewed? |
| universe | Which | | Distinctive | Which options or trade-offs are available, and what constraints apply? |
Novice questions:
Definition The social platform:
Nurturing the shared goal:
- Nature of the item. E.g. innovation, infrastructure upgrade, tooling license, team capacity.
- Anchors the semantic definition for the pupose it should serve.
- policies and permissions that steer access for actvities CoP)
- regularly feed with external expertise and promote access to other networks (CoP)
|
Category Enabling processes:
- Reveals cost breakdowns, funding models (CapEx vs OpEx)
- Allocation logic,fixed vs variable, centralized vs decentralized
- Convening opportunities to create and encourage interactions (CoP)
- Ineractions Communication, connection and conversation (CoP)
|
Class Practices:
- Maps budget to domains—CI/CD, observability, security, cloud spend—ensuring
- Maps to correct scope and impact zone
- norms and rules guiding behavior (CoP)
- Ensure for strong leadership participation (CoP)
|
Identity Purpose scope:
- Identifies accountable roles—product owner, finance controller, platform lead
- Enabling traceability and escalation
- Get the core group to steer the community (CoP)
- Set the strategic direction by distinctive -Who- (CoP)
|
Timing Performance:
- Aligns timing—quarterly planning, sprint budgeting, release windows
- Aligns to lifecycle and governance cadence
- Governance indicators that are used (CoP)
- Convening opportunities/events fit in general (CoP)
|
Distinctive Govern and sponsor:
- Enables scenario modeling—e.g., invest in automation vs scale team
- defer upgrade vs absorb risk—embedding recursive evaluation and prioritization logic
- Support needed from management (CoP)
- get involvment & create participation opportunities (CoP)
|
Portfolio - budget Alignment 6*6 Matrix: Semantic Mapping
Questions to structure Portfolio - budget understanding across context layers & abstraction layers.
❶ Alignment by What en How:
| What (define) | How (Categorize) |
| Initiative | What is the purpose & scope? | How grouped by: strategic, compliance, innovation? |
| Budget Item | What is the type: capex, opex? | How categorized: fixed, variable, discretionary? |
| Resource | What resources: people, tech, capital? | How is it classified: internal, external? |
| Constraint | What limits: budget, policy, capacity? | How are constraints structured: hard/soft? |
| Outcome | What expected value or impact? | How is success measured: KPIs, ROI? |
| Scenario | What scenario: baseline - stretch? | How is it modeled: assumptions, drivers, framework? |
❷ Alignment by Where en Who:
| Where (Classify) | Who (Name) |
| Initiative | Where does it apply (domain, geography, BU)? | Who sponsors or owns it? |
| Budget Item | Where is it allocated (cost center, project)? | Who approves or consumes it? |
| Resource | Where is it sourced or deployed? | Who provides or manages it? |
| Constraint | Where do they impact planning? | Who enforces or negotiates them? |
| Outcome | Where does value manifest (customer, org)? | Who benefits or is accountable? |
| Scenario | Where does it diverge from current state? | Who owns the scenario logic? |
❸ Alignment by When en Which:
| When (Time) | Which (Distinguish) |
| Initiative | When is it planned or executed? | Which initiatives compete or overlap? |
| Budget Item | When is it spent or forecasted? | Which items are critical vs deferable? |
| Resource | When is it available or constrained? | Which resources are bottlenecks or enablers? |
| Constraint | When do they apply or expire? | Which constraints are negotiable? |
| Outcome | When is value realized? | Which outcomes are prioritized? |
| Scenario | When is it relevant (planning horizon)? | Which scenario is most viable? |
Retrospective for Stakeholder and Portfolio/Plan
Issues The understanding continuum for enterprises by concepts resulted in the question who the stakeholders are, what they want to be solved or improved.
That should give an answer for the
Why of a follow-up in activities.
The why stated by a vison that is transformed into missions:
❶ There is a duality hidden by the stakeholders origin.
In the ID a part of flow is embedded
<discipline>StakeHolder<:S/I/A/R>:_xxx
⏳ The dualities in the stakeholders types are a balancing act:
Purpose:
- A Technology : What is technological possibl, what should be replaced (technical debt)
- S Administration: What is possible to govern what should be replaced (managerial debt)
Budget:
- I Backend: budget and other values to spent for getting materials and components.
- R Frontend: budget and other values bringing in enabling fulfilment of wishes.
❷ Purpose and budget are not parallel structures, two tracks that coexist, they are rather a dynamic tension that must be choreographed at every understanding step.
👉🏾 Accountability Responsibility of purpose-budget should become the shared mission.
❸ The balancing act in purpose and budget is what the system does.
👉🏾 What is missing:
- Explicit choreography between purpose and budget. Transformations don’t declare how safety constrains or enables functionality.
- A shared recursion logic, “Which” decisions don’t yet embed budget trade-offs or fallback paths.
- Dual-role dashboards, System-2 oversight, is implied but not visualized across both dimensions.
- In maturity alignment the purpose missions aren’t phased alongside budget-value evolution.
⌛ Reframing the Duality Purpose vs Budget:
| Aspect | Purpose (Creation) | Budget (Constraint) | Integration Logic |
| Intent | Declares the mission, goals, and systemic value of the concept | Defines resource boundaries, funding logic, and prioritization constraints | Purpose must be mapped to budget lines with declared value drivers and trade-offs |
| Transformation | Frames what should be transformed and why (semantic readiness) | Limits what can be transformed based on cost, risk, and feasibility | “Which” decisions must balance mission fit with resource viability |
| Time-Slice | Suggests when the concept should be instantiated (Now/Near/Far Future) | Determines when funding is available or allocated | Time-slice must align with budget cycles and readiness gates |
| Stakeholder | Identifies who defines and validates the concept’s purpose | Identifies who controls funding, approves spend, and monitors ROI | Role-flow must include both purpose owners and budget custodians |
| Metrics | Measures mission fit, stakeholder alignment, and semantic completeness | Measures cost efficiency, resource utilization, and financial risk | Dashboards must show dual metrics: Purpose Coverage Score + Budget Utilization Index |
| Governance | Ensures legitimacy, trust, and alignment with systemic goals | Enforces compliance, auditability, and fiscal responsibility | System-2 must orchestrate both semantic and financial convergence |
👉🏾 Using a dynamic system is changing the old approach of delivering static documents.
Pupose/budget aren’t just some events it’s a semantic construct that bridges prupose, value driven by stakeholders across abstraction layers.
AK-2.2 Purposeful & safe information systems I
Using and changing systems are several levels of abstraction.
The transformations for the desired functionality are combined to uncertainty ambiguity in possible multiple aspects.
Challenges for the Enterprise concepts:
- Concepts: purpose, selection criteria, implementation patterns, features/performance vs safety/regulation.
- Domain: S (Control) & R (Functioning)
governance shaping for the purpose avoiding unwanted effects.
- Owner: Chief Engineer, Safety Officer + Architecture Board.
⟲ AK-2.2.1 Information transformations concepts in abstractions
Product/service ownership to get first focus
Product/service ownership is not a static reference, it serves as semantic anchor within the ZARF multidimensional grid in supporting clarity, traceability, and transformation across abstraction layers and interrogative flows.
⏳ Product/service ownership:
- defines the semantic boundaries for valid transformations, semantic contract between roles and systems.
E.g. only certain roles are responsible for specific actions.
- information inherits and propagates governance constraints, a recursion anchor for “Which” decisions at every abstraction level.
E.g. product/service delviery promises and quality rules.
- encodes dependency logic, boundary object across flows (engineering, administration, delivery, supply).
E.g. a products/services must get created before validated into deliveries.
- shapes external identity and trust, a legitimacy enabler, aligning internal structure with external expectations (safety, wealth, fame, honor).
E.g. how a system presents its catalog, roles, or services to the outside world.
Product/service ownership is not just a title but is about interactions, habits and behavior.
Less abstract:
| 6w1h | Master data reference | Example |
| What: | Promises Product/Service external deliveries | Found in the portfolio & innovations. |
| How: | Specfication schemes using taxonomies | Using & creating Instructions for constructions. |
| Where: | Location hierarchies, jurisdiction zones | Warehouse locations, Legal agreements. |
| Who: | Role definitions, organizational units | Inventor,Constructor - Development, Operations. |
| When: | Temporal anchors, lifecycle states | Product/service valid-from dates, Maturity stages. |
| Which: | Decision criteria, disambiguation logic | Product eligibility rules, usability, aplicability. |
Each of these is instantiated across abstraction layers—from conceptual (e.g. stakeholder roles) to operational (e.g. user accounts, cost centers).
⌛ Example for a role within managing the portfolio:
- Domain - System Logic : Role = "Functionality & Functioning - Constructor"
Alternative titles: Chief Engineer, Chief Product Officer, Product Owner.
- Semantic Function : Ensures product/service integrity for external result deliveries by all involved transformations.
- Governance: Must be assigned before a "Which/Why" decision of the product functionality & functioning is finalized.
- Interaction: Feeds into domains:
- "Master Data - How": Ensuring system integrity in concept models, category & risk.
- "System Logic - What": task design for differentiate supply external & internal.
- “Technology - What”: choices & preferences for platforms to use.
💣 The word "product-owner" (scrum: component tool) results to: uncertainty & ambiguities.
The business products/services conceptual goals
What is leading in functionality and functioning is the lean discipline in several kind of approaches.
An important aspect of lean is the mapping of values stream across boundaries.
Value streams are not isolated nor limited to the operational construction stage.
⏳
What Most Companies Miss about the
Role of Chief Engineers (LEI 2025 J.Morgan, J.Liker)
The organizational focus needs to be on making the horizontal value streams, the product programs and therefore the CE successful.
This priority should be reflected in your operating system and your leadership behaviors across the organization:
- Allow CEs to focus on their products, don't overburden them with people-development responsibilities, always solicit their input on people that contribute to their program(s).
- Establish your most important team metrics based on product success.
- Build CE-centric tools and methods into your development process.
E.g. The concept paper, kickoff meetings, and CE reviews
- Create CE-centric senior leader forums within your system to promote a product-first focus.
- Groom some of your best people for the CE role and provide appropriate recognition.
💣 There should be a role/task covering the accountability and responsibility, if that is not the the case it will get done in made assumptions by others.
The ownership for the product/service is pivotal for the system that serving the product/service.
The role/task of the CE (Chief Engineer):
The chief engineer is unwaveringly customer-focused, always keeping the end customer’s needs and preferences at the forefront of the development process.
They are dedicated to ensuring that the product/service not only meets but exceeds customer expectations for quality, performance, and usability.
This involves continuously seeking and incorporating target customer feedback, analyzing market trends, and making decisions with the customer’s satisfaction in mind.
That is a statement in expectations where more concreteness is expected.
⌛ There is a difference for concepts by functionality and functioning related to the difference in transformations and materialisations.
How these are connected in their differences:
| Context | Transformations | Materialisations |
| 🔰Purpose: | Translate strategic goals into executable architectures and platform logic | Deliver resilient systems aligned with stakeholder intent and operational constraints |
| 🔰Focus: | Orchestrate recursive “Which” decisions balancing trade-offs and constraints | Instantiate validated blueprints into operational platforms and feedback loops |
| 🔰Structure: | Engineer transformation paths across abstraction layers and time slices | Realize modular components, interfaces, and control logic with semantic traceability |
| 🔰Usage: | Embed feedback loops, maturity logic, and good regulator principles | Operationalize systems with observability, safety axioms, and role-task clarity |
| 📚Artifacts: | Construct transformation maps, dependency chains, and orchestration logic | Materialize systems: platform instantiations, telemetry, and closed-loops metrics. |
| 📚Temporal: | Phase transformations across time slices with convergence and rollback paths | Deliver time-sliced systems with adaptive triggers and exception handling |
| 📚Roles: | Coordinate multi-cell transformations with System-2 logic and stakeholder alignment | Instantiate accountable roles across abstraction layers and operational domains |
| 📚Philosophy: | Balance control vs. influence, functioning vs. functionality, internal vs. external | Materialize systems that reflect human values, legitimacy, and adaptive resilience |
The "Product / service" improvement practices
Mapping of product / service conceptual model to make it more practical.
By six steps there is the engineering approach (6w1h axis):
- Function : What the Product /service is by goal for usage and in using / consuming
- Mechanism: How the Product /service is constructed conform specs
- Interface: Where the Product /service is constructed
- Agent: Who is accountable responsible for the Product /service
- Time/timing: When the Product /service is available, delivered, serviced
- Purpose/Safety: Which/why the Product/service offered, promised to external customers
⏳
The mapping of the product / service improvement practice the abstraction levels are far more ambiguous.
The common used words matter in the understanding.
👉🏾Improving functionality or functioning purpose - bottom-up:
sustainable teambuilding people (M.Cardus 2025)
When productivity stays flat while workload climbs, it’s rarely about effort.
It’s a sign the system is straining under the weight of its own interactions.
I use a flow that supports adaptive change: Data - Diagnose - Design - Development - Determine - Direct
| Stage | Actvities |
| Data | Team workload scores rise 25% over two quarters, but output per FTE remains unchanged. |
| Diagnose | The data points to entanglement, overlapping roles, unclear boundaries, and decision loops that slow momentum. Patterns, not people, are producing the drag. |
| Design | Visualize the work, create Experience Maps. Clarify interfaces, reduce unnecessary handoffs, and simplify where interdependencies have become constraints. |
| Development | Work with managers and teams to experiment with new ways of coordinating, shifting from control to coherence. |
| Determine | After six months, teams recovered about 8 hours per person per week, throughput improved 10%, and “I can get my work done effectively” scores rose 12 points. |
| Direct | Without actions for realisation all the work done for the improvement is useless. |
The cycle matters: Data signals tension. Diagnosis explores the pattern. Design creates new conditions.
Development builds adaptive capacity. Determine shows what shifted and what the system still needs to learn.
👉🏾 Improving Functioning for safety - bottom-up:
Demarcation the sixth D.
Physical security is often broken down into a set of general concepts, the big “D's” of security – Deter, Detect, Deny, Delay, and Defend.
This division of function is useful for reducing a complex security problem into a set of simpler ones that can be systematically addressed.
A clear demarcation of the perimeter is so vital to the overall security and efficient operation of a site that demarcate can be considered the sixth “D” of security.
The order with an indication of process transformations:
- Demarcation, By clear boundaries, answers where to enforce access controls. (Segmentation)
- Deny, When a denial fails, slowing down an attacker gives your team more time to react.
- Delay - As adversaries hit friction, overt deterrents reinforce that the environment is hostile.
- Deter, When deterrence fails, an environment primed for visibility spot intruders faster.
- Detect, With timely detection, your incident response playbooks activates, before escalatation.
- Defend Be ready to act for timely actions on threats.
⌛ Example:
Applying Product service descriptions in the context of "Customer Interaction" conceptual modeling:
| Zarf | Context in Concepts for getting details |
| Function | Deliver personalized product/service experiences based on customer needs, preferences, and context. |
| Mechanism | Use CRM systems, recommendation engines, and feedback loops to adapt dynamically. |
| Interface | Multichannel touchpoints: web portals, mobile apps, chatbots, in-store kiosks, and human agents (service desk, sales, technical support). |
| Agent | Customer (initiator), Service Advisor (facilitator), Product System (responder), Feedback Engine. connected to analysis in time/timing. |
| Time/timing | Real-time interaction for support; scheduled follow-ups; lifecycle-based engagement. Service in place by pre & post sale. |
| Purpose/Safety | Have mandatory standards for safety in place. Ensure trust, relevance, and compliance; protect customer data; align with brand values and ethics. |
⟲ AK-2.2.2 Concept: Functionality transformations purpose missions
Mapping of abstraction semantic for using BRules
The top-down approach (PDCA) is using different words than bottom-up (dmaic).
In a dynamic system the direction is undefined but the humans in the system have different perspectives.
For both Functionality purpose & safety there are two sets of words:
- Functionality purpose
Note: The top-down approach (PDCA) is using different words than bottom-up (dmaic).
- Functionality safety
Note: this is the antipode of DevOps, they are the duality in enabling value streams.
| ViSM | Semantic | 👐 | Logic Functional | Logic Functioning | 👐 | safety Functional safety | Safety Functioning |
| universe | Context | | ⬇ Mission Fit | ⬆ Direct | | ⬇ Responsibility | ⬆ Demarcation |
| system-5 | Concept | | ⬇ Transforms | ⬆ Determine | | ⬇ Dependencies | ⬆ Deny |
| system-4 | System Logic | | ⬇ Boundaries | ⬆ Development | | ⬇ Constraints | ⬆ Delay |
| system-3 | Technology | | ⬇ Lifecycle | ⬆ Design | | ⬇ Risks | ⬆ Deter |
| system-2 | Components | | ⬇ Monitoring | ⬆ Diagnose | | ⬇ Monitoring | ⬆ Detect |
| system-1 | Instance | | ⬇ Performance | ⬆ Data | | ⬇ Mission Fit | ⬆ Defend |
Functionality purpose Alignment Matrix: Semantic Mapping
Questions that help structure stakeholder understanding in enabling role clarity, decision traceability, and governance alignment across context layers.
Simple questions:
| ViSM     | 6w1h | 👐 | Zarf | Functionality Logic role alignment focus |
| system-1 | What | | Function | What does this functionality do, what promise it fulfill? |
| system-3 | How | | Mechanism | How is it executed, mechanisms - algorithms are used? |
| system-4 | Where | | Interface | Where are interactions with other systems or roles/tasks? |
| system-5 | Who | | Agent | Who (role-task) is responsible, by monitoring, validating? |
| system-2 | When | | Time/timing | When is this functionality active and what lifecycle does it follow? |
| universe | Which | | Purpose/Safety | Which option balances best in: safety vs purpose - other trade-offs? |
Novice Questions:
Function Shared goals in mission statements: (Constructor, Inventor)
- What concept or capability is being transformed?
- How to recognize a semantic need or opportunity?
- What facilitation methods are needed to get the best out of the processes? (CoP)
- How to measure key results, capture impacts in deliveries for objectives? (CoP)
|
Mechanism Structure the solution concept by: (Philosopher2, System Framer2)
- How will the transformation be executed?
- What is the Selection method for tools, or processes?
- What make members collaborate and/or cooperate? (CoP)
- How to ensure a user-centric experience for the tasks? (CoP)
|
Interface Geography for the solution in interfaces: (Validator, Cartographer2)
- Where does the transformation occur (domain, platform)?
- Which mapping to operational or cyber-physical space Map to planes or layers?
- Which tools & methods are supplied by management in their role/tasks? (CoP)
- Which rituals & routines to sustain engagement, processes & content? (CoP)
|
Agent Knowledge in who is who: (Diplomat, Healer)
- Who owns, executes, and validates the transformation?
- What are the role-task assignments and accountability?
- What are the personas in their requirements & pain points to address? (CoP)
- Who does the coordination towards delivering on agreed objectives? (CoP)
|
Time/Timing Impact of the solution visible to stakeholders: (Trickster, Prophet2)
- When should the transformation occur (time-slice)?
- When and how is it triggered by readiness, priority, or dependency?
- What are capability metrics: curated/synthesised/co-created? (CoP)
- Which closed loops for: achievements, lessons learned, obstacles to address? (CoP)
|
Purpose/Safety The solution being unambiguous in: (Philosopher2 , Prophet2)
- Which option or specification is selected?
- Which decision among viable paths or fallback logic are made?
- Which created knowledge, habits and behaviours are to encourage? (CoP)
- Which flow between real & online, asynchronous & synchronous is ensured? (CoP)
|
Functionality purpose Alignment 6*6 Matrix: Semantic Mapping
Questions to structure: Functionality purpose understanding across context & abstraction layers.
❶ Alignment by What en How:
| What (define Function) | How (Categorize Mechanism, Algorithm) |
| Mission Fit | What is the product/service scope? | How is it delivered by what logic? |
| Transforms | What is the functional need? | How is the process designed? |
| Boundaries | What are the capability maps? | How is it controlled by what logic? |
| Lifecycle | What are the components specs? | How is the execution logic in specifications? |
| Monitoring | What are the config options? | How is it automated by what logical rules? |
| Performance | What is the actual behavior? | How is the flow, value stream specified? |
❷ Alignment by Where en Who:
| Where (Classify Interface) | Who (Name Agent) |
| Mission Fit | Where is the channel mapping applied? | Who is who, role mapping, for functionality? |
| Transforms | Where are the interactions in the flow? | Who acts for what kind of logic (role/task)? |
| Boundaries | Where in what API/UX Layer is it serviced? | Who (role/task) fits for specified activities? |
| Lifecycle | Where are integrationpoints, what impacts? | Who (role/task) facilitates agents? |
| Monitoring | Where does deployment targets manifest? | Who (role/task) facilitates operator(s)? |
| Performance | Where does the live interface manifest? | Who is accountable for activities by agents? |
❸ Alignment by When en Which:
| When (Time Timing) | Which (Distinguished Purpose) |
| Mission Fit | When has this purpose active window(s)? | Specs define the purpose? |
| Transforms | When are interaction triggers active? | Specs of interfaces interactions? |
| Boundaries | When are the events in boundaries active? | Specs of relevant API/UX boundaries? |
| Lifecycle | When runs the operations by schedules? | Specs in constraints for schedules? |
| Monitoring | Knowledge by closed-loops for events? | Specs of outcomes are prioritized? |
| Performance | Knowledge for Value streams in events? | Specs scenarios that are most viable? |
⟲ AK-2.2.3 Information transformations safety in abstractions
The yin-yang dance between creating and safety.
This metaphor sets the balancing act: innovation with governance, freedom with constraint, and transformation with trust.
Every transformation from concept to functionality is a negotiation, a dynamic interplay between the creative impulse to shape something new and the systemic need to preserve safety, trust, and continuity.
- Creation brings novelty, divergence, and adaptive potential. It asks: What could this become?
- Safety brings structure, convergence, and legitimacy. It asks: What must this remain?
⏳
The assumption is products are tangible goods, services offer intangible value through the time, expertise, and support they provide to their clients.
In the information age products are becoming intangible it is about knowledge of all kind, insurance, a performance show (music act dance etc.), patents including software patents, brand-reputation or financial value.
Financial values have moved and are moving to be intangible (bank-accounts) where they were once metal coins.
Understanding how this all is by differences impacting on actions promises is a social shift. The change not all products are tangible.
Thus, every product or service instantiated from a concept must carry both:
- A creative signature, “Which” of options, trade-offs, and domain-specific adaptations.
- A safety imprint, the “When” of timing, convergence, exception handling, and rollback logic.
⌛
Example: Applying this in the context of "Adaptive Transit Planning" Functionality.
Strategic:
| Human Label | Clear, stakeholder-friendly name, E.g “Adaptive Transit Planning” |
| Formal Definition | A concise, unambiguous description of what the product/service is and does.
Example: “A dynamic route optimization system that adapts public transport schedules based on real-time demand, weather, and service disruptions.” |
| Purpose / Mission Fit | What systemic goal does this fulfill?
E.g., “Increase urban mobility inclusivity while reducing carbon footprint.” |
| Stakeholder Roles | Who defines, validates, and uses this?
E.g., City Planner, Transit Operator, Citizen, Regulator. |
Methodology:
| Value Drivers | Which human motivations are activated?
E.g., Safety (work traffic), Wealth ( cultural events traffic), Honor, Fame |
| Time-Slice Readiness | When is this concept expected to be instantiated?
Now / Near Future / Far Future |
| Semantic Boundaries | What must this concept not violate?
E.g., “Must not override emergency vehicle priority routes.” |
| Transformation Trigger | What event or condition activates this concept’s instantiation?
E.g., “Demand exceeds 120% of baseline for 3 consecutive days.” |
Practice:
| Concept ID | Unique identifier. E.g: PT-001 |
| Portfolio Link | What budget or program funds this?
E.g.: “Urban Mobility 2030 Initiative” |
“Which” Decision Logic | What options were considered, and why was this one chosen?
E.g., “Chosen over static scheduling due to higher resilience and citizen satisfaction.” |
Coordinator (System-2) | Who governs transformation & convergence?
E.g “Mobility Governance Board” |
Inseparability for functionality & safety
Your incident plan isn't tested unitl it meets the first 10 minutes of chaos
Why most incident response plans fail in the first 10 minutes. (LI David Clarke 2025)
Not because of poor tech, Not because of lack of budget, but because the first people to act don’t know what not to do.
In every major incident I’ve reviewed, the breakdown starts with panic actions:
- IT resets a compromised account - wiping forensic evidence.
- Someone emails the breach details - unsecured.
- Legal isn’t looped in early enough - triggering late regulator notification.
- No one takes lead - so everyone reacts.
The first 10 minutes are chaos unless they’re rehearsed.
Good plans fail because they’re too long, too vague, or stored where no one checks.
The best ones?
Fit on a single page.
- Assign exact roles, even for the first responder.
- Include a “first 5 actions” checklist.
- Are drilled quarterly, not just reviewed annually.
- Your plan is only as strong as your worst-prepared team member on their worst day.
- If you haven’t tested your first 10 minutes in a live exercise, assume it will fail.
Fix it now not in a breach.
👉🏾 This should be part of concerns that go into requirements for specifications.
The Specifications documetns shoudl be a good description of what a prodcut/service is, what the functionality is, how is hould be used and how it should be maintained.
What we prep before the breach:
- Isolation protocols that don’t need six approvals
- Decision logs that stand up to audit
- Regulator-ready timelines pre-mapped
- Internal comms that prevent finger-pointing
- Legal & privacy leads briefed in advance
If your breach plan lives in a PDF no one’s opened since onboarding, we should talk.
The concepts of functionality in the good and bad
The requirements that are open to be realised are propagations van the suggestions, concerns backlog items that are agreed in having got a status for allowed to get worked on.
⏳
The data model structure is similar to that of concerns with the differences:
- Concern ➡ Requirement
- Specifications referenced ➡ Concerns referenced
The propagations are triggered by human decisions by someone being responsible for the whole of the product/service e.g. the CE.
⌛ The product/service specfication (PSSP) items:
- ID: <discipline>:PSSP_www:<sub-discipline domain descriptive short text >
- <discipline>:PSSP_www:SpecsI_iii:<Purpose within sub-discipline descriptive short text>
- SpecsD_: <Understandable descriptive text in value and choice(s) >
- Form: <Descriptive type of used components>
- Lifecycle Phase: <Initiation/Research/Development/Validation/Active/Retired>
- Temporal: <time window for concern relevance>
- Stakeholder Roles
- Responsible: ➡ <discipline>:StakeHolder:M:_?
- Constructor: ➡ <discipline>:StakeHolder:E:_?
- Validator: ➡ <discipline>:StakeHolder:V:_?
- Consumer: ➡ <discipline>:StakeHolder:C:_?
- SafetyTRust1* ➡ < safety & trust references s>
- 1* Related-S:Product-Service_www:SpecsI_?:SpecsD_?
- Temporal: <time window for concern relevance>
- 1* Related-S:Component-Platform_qqq:SpecsI_?:SpecsD_?
- Temporal: <time window for concern relevance>
This can be indexed, visualized, and cross-linked in semantic dashboards using a relational storage system.
Traceability auditability of the state is achieved by the documenting in knowledge by the temporal relationships.
A data model for managing knowledge for systems, Jabes.
👐 The governance of safety for information systems is Volatile, Uncertain, Complex and Ambigious.
| Confidentiality | Integrity | Availablity | Impact Engagement |
| High | High | High | Co-create & consult - CSO |
| High | High | Low | Co-create & consult - CDO |
| High | Low | High | Co-create & consult - ? |
| High | Low | Low | Co-create & consult - DPO |
| Low | High | High | ? |
| Low | High | Low | ? |
| Low | Low | High | ? |
| Low | Low | Low | Monitor passively - ? |
See right side.
For all kind of safety requitements the interactions to stakeholders are classified using a dual-axis matrix.
💣 There are weird gaps, a classic:
- CSO (Chief security officer) deals with the CIA triad
- CDO (Chief data officer) deals with integrity and PII
- DPO (Data protection office) with PII
There is no overall coverage for all possible options.
The only way out of this dilemma is have the CSO CDO DPO as advisory roles and the accountability responsibility of functionality and safety shared in the same role/task.
⟲ AK-2.2.4 Concept: Functionality transformations safety missions
Functionality Safety Alignment Matrix: Semantic Mapping
Questions that help to structure functionality safety understanding in enabling role clarity, decision traceability, and governance alignment across context layers.
Both should be in place, the purpose in functionality and safety with the solution for the purpose.
Simple questions:
| ViSM     | 6w1h | 👐 | Zarf | Functionality Logic role alignment focus |
| system-1 | What | | Function | What does this functionality do, what promise it fulfill? |
| system-3 | How | | Mechanism | How is it executed, mechanisms - algorithms are used? |
| system-4 | Where | | Interface | Where are interactions with other systems or roles/tasks? |
| system-5 | Who | | Agent | Who (role-task) is responsible, by monitoring, validating? |
| system-2 | When | | Time/timing | When is this functionality active and what lifecycle does it follow? |
| universe | Which | | Purpose/Safety | Which option balances best in: safety vs purpose - other trade-offs? |
Novice questions:
Function Shared goals in mission statements: (Constructor, Inventor)
- What concept or capability is being transformed?
- How to recognize a semantic need or opportunity?
- What facilitation methods are needed to get the best out of the processes? (CoP)
- How to measure key results, capture impacts in deliveries for objectives? (CoP)
|
Mechanism Structure the solution concept by: (Philosopher2, System Framer2)
- How will the transformation be executed?
- What is the Selection method for tools, or processes?
- What make members collaborate and/or cooperate? (CoP)
- How to ensure a user-centric experience for the tasks? (CoP)
|
Interface Geography for the solution in interfaces: (Validator, Cartographer2)
- Where does the transformation occur (domain, platform)?
- Which mapping to operational or cyber-physical space Map to planes or layers?
- Which tools & methods are supplied by management in their role/tasks? (CoP)
- Which rituals & routines to sustain engagement, processes & content? (CoP)
|
Agent Knowledge in who is who: (Diplomat, Healer)
- Who owns, executes, and validates the transformation?
- What are the role-task assignments and accountability?
- What are the personas in their requirements & pain points to address? (CoP)
- Who does the coordination towards delivering on agreed objectives? (CoP)
|
Time/Timing Impact of the solution visible to stakeholders: (Trickster, Prophet2)
- When should the transformation occur (time-slice)?
- When and how is it triggered by readiness, priority, or dependency?
- What are capability metrics: curated/synthesised/co-created? (CoP)
- Which closed loops for: achievements, lessons learned, obstacles to address? (CoP)
|
Purpose/Safety The solution being unambiguous in: (Philosopher2 , Prophet2)
- Which option or specification is selected?
- Which decision among viable paths or fallback logic are made?
- Which created knowledge, habits and behaviours are to encourage? (CoP)
- Which flow between real & online, asynchronous & synchronous is ensured? (CoP)
|
Functionality safety Alignment 6*6 Matrix: Semantic Mapping
Questions to structure Functionality safety understanding across context layers & abstraction layers.
❶ Alignment by What en How:
| What (define Function) | How (Categorize Mechanism ) |
| Responsibility | What is the product/service scope? | How is it delivered by safety logic? |
| Dependencies | What is the functional need? | How is the process designed? |
| Constraints | What are the capability maps? | How is it controlled by what logic? |
| Risks | What are the components specs? | How is the execution logic in specifications? |
| Monitoring | What are the config options? | How is it automated by what logical rules? |
| Mission Fit | What is the actual behavior? | How is the flow, value stream specified? |
❷ Alignment by Where en Who:
| Where (Classify Interface) | Who (Name Agent) |
| Responsibility | Where is the channel mapping applied? | Who is who, role mapping, for the safety? |
| Dependencies | Where are the interactions in the flow? | Who acts for what kind of safety (role/task)? |
| Constraints | Where in what API/UX Layer is it serviced? | Who (role/task) fits for specified activities? |
| Risks | Where are integration points, what impacts? | Who (role/task) facilitates agents? |
| Monitoring | Where does deployment targets manifest? | Who (role/task) facilitates operator(s)? |
| Mission Fit | Where does the live interface manifest? | Who is accountable for activities by agents? |
❸ Alignment by When en Which:
| When (Time Timing) | Which (Distinguished Safety) |
| Responsibility | When has this purpose active window(s)? | Specs define the safety? |
| Dependencies | When are interaction triggers active? | Specs of interfaces interactions? |
| Constraints | When are the events in boundaries active? | Specs of relevant API/UX boundaries? |
| Risks | When runs the operations by schedules? | Specs in constraints for schedules? |
| Monitoring | Knowledge by closed-loops for events? | Specs of outcomes are prioritized? |
| Mission Fit | Knowledge for Value streams in events? | Specs scenarios that are most viable? |
Retrospective for Functionality and Safety
Issues in the concept model for a product/service to solve:
❶ The duality functionality-safety are seen as parallel structure—two tracks that coexist—rather than a dynamic tension that must be choreographed at every transformation step.
👉🏾 Accountability Responsibility of functionality-safety should be shared in the same role/task.
❷ Other words are used in the top-down and bottom-up mindset although the intention is the same.
❸ That usage of different words happens for both inseparable contexts functionality and safety.
⏳ These four sets should be aligned in concept models.
Functionality:
- Technology : Direct ⇆ Determine ⇆ Development ⇆ Design ⇆ Diagnose ⇆ Data
- Administration: Mission Fit ⇄ Transforms ⇄ Boundaries ⇄ Lifecycle ⇄ Monitoring ⇄ Performance
Safety:
- Technology: Demarcation ⇆ Deny ⇆ Delay ⇆ Deter ⇆ Detect ⇆ Defend
- Administration: Responsibility ⇄ Dependencies ⇄ Constraints ⇄ Risks Monitoring ⇄ Mission Fit
👉🏾 What is missing:
- Explicit choreography between functionality and safety. Transformations don’t declare how safety constrains or enables functionality.
- A shared recursion logic, “Which” decisions don’t yet embed safety trade-offs or fallback paths.
- Dual-role dashboards, System-2 oversight, is implied but not visualized across both dimensions.
- In maturity alignment the Safety missions aren’t phased alongside functionality evolution.
❓ Why all this effort?
What is the diffference to classic project management e.g. Prince2?
- Zarf operates at a semantic modeling level, while PRINCE2 is procedural and operational.
- Zarf supports recursive modeling and fractal instantiation; PRINCE2 is linear and phase-based.
- Zarf embeds safety, wealth, fame, honor as systemic drivers; PRINCE2 does not.
- Zarf supports multi-cell transformations with System-2 coordination; PRINCE2 assumes a single project flow, fixed in stages (waterfall).
❓ What about the strange duality in stakeholder roles?
- The operational execution: <discipline>:StakeHolder<:M/E/V/C>:_xxx
- The policy decisions are: <discipline>:StakeHolder<:S/I/A/R>:_xxx
There are more types but these are the ones for operations and cahnge.
⌛ Reframing the Duality Functionality vs Safety:
| Aspect | Functionality (Creation) | Safety (Constraint) | Integration Logic |
| Intent | Deliver capability, value, and mission fit | Preserve trust, legitimacy, and systemic integrity | Every capability must declare its safety envelope |
| Transformation | “Which” option is chosen to fulfill purpose | “When” and “What if” define fallback and exception paths | Recursive “Which” must include safety trade-offs |
| Time-Slice | Active in Now/Near Future instantiations | Governs Far Future implications and rollback logic | Time-slice must declare convergence and safety maturity |
| Stakeholder | Constructor, Operator, Beneficiary | Validator, Custodian, System-2 Coordinator | Role-flow must include dual accountability |
| Metrics | Performance, usability, mission success | Risk containment, exception frequency, trust score | Dashboards must show both dimensions side-by-side |
| Governance | Agile, adaptive, outcome-driven | Auditable, bounded, exception-aware | System-2 must orchestrate both flows in tandem |
👉🏾 Using a dynamic system is changing the old approach of delivering static documents.
Product/service isn’t just a deliverable, it’s a semantic construct that bridges functionality, value, and stakeholder resonance across abstraction layers.
AK-2.3 Purposeful & safe information systems II
Using and changing systems are several levels of abstraction.
The information artifacts materialisations in the desired functionality are combined to uncertainity ambiguity in possible multiple aspects.
Challenges for the Enterprise concepts:
- Concepts: data semantics, datasets used, subjects impacted, retention/lifecycle.
- Domain: A (Adaption) & S (Control) Be aware: 💣 diagonal tensions.
governance shaping for the purpose avoiding unwanted effects.
- Owner: Data Steward + Legal/Privacy.
⟲ AK-2.3.1 Information instantiations for purpose in abstractions
Product/service solution to get next focus
Product/service ownership is not a static reference, it serves as semantic anchor within the ZARF multidimensional grid in supporting clarity, traceability, and transformation across abstraction layers and interrogative flows.
⏳ Product/service ownership:
- defines the semantic boundaries for valid transformations, semantic contract between roles and systems.
E.g. only certain roles are responsible for specific actions.
- information inherits and propagates governance constraints, a recursion anchor for “Which” decisions at every abstraction level.
E.g. product/service delviery promises and quality rules.
- encodes dependency logic, boundary object across flows (engineering, administration, delivery, supply).
E.g. a products/services must get created before validated into deliveries.
- shapes external identity and trust, a legitimacy enabler, aligning internal structure with external expectations (safety, wealth, fame, honor).
E.g. how a system presents its catalog, roles, or services to the outside world.
Product/service ownership is not just a title but is about interactions, habits and behavior.
Less abstract:
| 6w1h | Master data reference | Example |
| What: | Promises Product/Service external deliveries | Found in the portfolio & innovations. |
| How: | Specfication schemes using taxonomies | Using & creating Instructions for constructions. |
| Where: | Location hierarchies, jurisdiction zones | Warehouse locations, Legal agreements. |
| Who: | Role definitions, organizational units | Inventor,Constructor - Development, Operations. |
| When: | Temporal anchors, lifecycle states | Product/service valid-from dates, Maturity stages. |
| Which: | Decision criteria, disambiguation logic | Product eligibility rules, usability, aplicability. |
Each of these is instantiated across abstraction layers—from conceptual (e.g. stakeholder roles) to operational (e.g. user accounts, cost centers).
⌛ Example for a role within managing the portfolio:
- Domain - System Logic : Role = "Functionality & Functioning - Constructor"
Alternative titles: Chief Engineer, Chief Product Officer, Product Owner.
- Semantic Function : Ensures product/service integrity for external result deliveries by all involved transformations.
- Governance: Must be assigned before a "Which/Why" decision of the product functionality & functioning is finalized.
- Interaction: Feeds into domains:
- "Master Data - How": Ensuring system integrity in concept models, category & risk.
- "System Logic - What": task design for differentiate supply external & internal.
- “Technology - What”: choices & preferences for platforms to use.
💣 The word "product-owner" (scrum: component tool) results to: uncertainty & ambiguities.
The goal and knowledge stability
The operations dashboard (I.Carillo 2025 - Toyoada)
Reading Sakichi Toyoda's 1924 loom patent, I found something nobody talks about. Here's the story:
- Sakichi asked a simple question: "Why are humans doing what machines could do better?"
- His automatic loom didn't prevent broken threads. It just raised a flag when one broke.
- Suddenly, one operator could monitor 30-50 looms. Not because people got faster. Because machines got more involved in human things.
Poka-Yoke is about freeing humans from mindless watching so they can apply judgment where it matters.
Fast forward 100 years.We have AI, IoT, and predictive analytics.
Yet I still see:
- Workers manually checking every part
- Operators glued to single stations
- Quality teams drowning in inspection paperwork
The operations dashboard (C.Roser 2025 - Toyoda)
In olden times, a worker – often a child with lower wages than an adult – had to supervise machines constantly, and if a warp broke, quickly had to tie it back together. Children working with moving machines with little concern for their safety is not a good combination.
Also note that the stop is only done to prevent bigger problems downstream and also to highlight the issue, making it more likely to be fixed!
Diving deep into the Toyota philosophy, you could see this as JIT telling you to let the material flow, and jidoka telling you when to stop the flow. This is a bit like the Chinese philosophical concept of Ying and Yang, where seemingly opposite or contrary forces may actually be complementary.
The same applies here. JIT encourages flow, and Jidoka encourages stops, which seems contrary. However, both help to produce more and better parts at a lower cost.
Unfortunately, JIT gets much, much more attention as it is the glamorous and positive side, whereas jidoka is often seen as all about problems and stops and other negative aspects.
Yet, both are necessary for a good production system.
Safety using information classifications
- It must be designed in such a way that you do not have to trust the supplier.
- Encryption helps against some risks, but when risks are miscalculated, it also creates unnecessary risks.
information asset classification (K van Wersch 2025)
ISO and NIST have shaped the way the world thinks about information security.
Their standards are widely used and for good reason: they provide structure, consistency, and a shared vocabulary.
- ISO 27002: Classification of information is a process that enables organisations to group information assets into relevant categories depending on the level of protection each category of information should be provided.
- NIST CSF: The data, personnel, devices, systems, and facilities that enable the organization to achieve business purposes are identified and managed consistent with their relative importance to organizational objectives.
The methodology begins with things you can inventory (files, systems, databases, devices) and only afterwards connects them to business purpose or impact.
And that's exactly where practice goes astray.
A context-first approach would begin with:
- Where does this information create value?
- What meaning does it carry in that context?
- Who is accountable for that context?
- Only then: apply tailored security measures, fitting for that context .
What gets lost in today's "asset-first" framing is context and meaning.
Here's how I believe it should flow:
- Identify the context where information lives and flows (enterprise architects).
- Understand meaning and value how information gains purpose (business analysts).
- Assign accountability - link responsible people to that context.
- Then apply information security - aligned with steps 1-3.
Until this shift is made explicit, "information asset classification" will keep pulling us into an object-first mindset and security will remain more of a compliance exercise than a true business enabler.
shop-floor functionality 7M process management
From 4M to 7M; from Chaos to Control (Alper Ozel 2025
- Universe ➡ (Where) Application Portfolio
Detect Abnormalities:
- Is the ambient temp, lightning and humidity controlled as required?
- Are are environmental conditions monitored and logged regular?
- Are dust, vibrations or external contaminations controlled?
- Is the shopfloor clean and organized (5s condition)?
- Is there evidence of sill validation or competence assessment?
- (Where) Application Portfolio ➡ (How) capability maps
Regulate to normal: (Man - People)
- Is the executive / operator certified or trained for the specific process?
- Are WI/SOPs clearly understood and accessible at the point of use?
- Are roles, responsibilities and shift handovers well defined?
- Is the executive / operator following standardized work procedures?
- Is there evidence of skill validation or competency assessments?
- (How) capability maps ➡ (What) master data management
Analyze Factors: (Measure - Technology)
- Is the system running within validated & approved parameters?
- Are PM schedules being followed and documented?
- Are abnormal noises, vibrations and leaks reported and addressed?
- Are interlock, sensors and emergency stops functioning properly?
- is the equipment setup/fixture as per the approved process sheet?
- (What) master data management ➡ (which) holistic overview
Understand Causes: (Method)
- Are standard operating procedure (Sops) available and followed?
- Is the actual process flow aligned with an approved control plan?
- Are process changes controlled and documented?
- Are poka-yoka (errorfree-proofing) methods installed & functioning?
- Are ergonomic & safety requirements considered in the methods?
- (Which) holistic overview ➡ (When) track your master flows
Establish Conditions: (e.g. Maintenance)
- Is PM being conducted as per schedule and documented?
- Are breakdowns recorded analysed amp closed with actions?
- Are critical spares available and stored properly?
- Are lubrications & cleaning standards displayed and followed?
- Are TPM boards, tags, or visual controls actively maintained?
- (Which) holistic overview ➡ (When) track your master flows
Establish Conditions: (e.g. Maintenance)
- Is the material trackability ensured from receipt to usage?
- Are incoming materials verified against specifications before use?
- Are material storage and FIFO practices followed?
- Is the material clean, undamaged and contamination free?
- Are handling requirements (e.g. temp, shelf-live) complied with?
- (When) track your master flows ➡ (Who) Track your ideas
Improve Conditions: (Measure)
- Are measuring instruments calibrated and within validated date?
- Are inspection results recorded and traceable?
- Are critical-to-quality (CTQ) parameters measured as per plan?
- is statistical process control (SPC) implemented for (CTQ's)?
- Are any NCs during measurement adresses through CAPA?
- (Who) Track your ideas ➡ Universe
Manage Conditions:
- (intentionally left empty)
This is where the X- Matrix lives.
⟲ AK-2.3.2 Concept: Functionality instantiations purpose missions
⟲ AK-2.3.3 Information instantiations safety in abstractions
EU CoP communities of practice
Generated summary:
The playbook was created to enhance collaboration and knowledge sharing within the European Commission through communities of practice.
- Communities of practice (CoP) are encouraged to overcome silo mentalities and improve data usage.
- The playbook is based on research and interviews with community managers, focusing on their successes and challenges.
- It aims to provide a framework for developing and sustaining communities in any organization.
Key success conditions include shared vision, participation, trust, and inclusive communication.
User personas represent groups of users based on empirical research, focusing on their goals and behaviors rather than demographics.
Personas should be specific and used for ideation within a defined scope.
Propose processes, tools, and methods that align with governance to meet identified needs.
Develop an operational model that addresses the needs of the majority while employing the KISS principle (Keep, Improve, Start, Stop).
Science Communities of Practice Playbook light (EU JRC july 2020)
You should approach the Communities of Practice Success Wheel by considering it as a circular journey–you can start anywhere, but eventually you will travel through all of the domains, as they are interwoven and interdependent.
We advise you to start with vision, but you can also chose to start where you feel you are struggling most in your community life at the moment.
The four Soft goals:
- Vision - Strategic shared agreement about the long-term mission and goals of the community.
- Governance - Structures and decision-making rules and practices that make sense and lead to co-ownership.
- Leadership - Leaders from both within the community and senior and middle management steer and invest in the community.
- Measurement Assessing community vitality - practices and behaviours, as well the results delivering on the objectives.
The four Rugged goals
- Convening - The art of to bringing the community together to connect members and engage them in meaningful conversations.
- Collaboration/cooperation - Working purposefully together towards delivering a community concrete deliverable.
- Community management - Facilitation of the synchronous and asynchronous flow of the community dynamic social processes.
- User experience - Ensuring a user-centric experience constantly adapting community workings and tools to the members' needs
(3.1.3) Outcomes:
- how to structure your design thinking along the eight Communities of Practice Success Wheel facets and how to (organise) work in every community feedback consultation;
- how to create a community roadmap, namely how to translate your community strategy into an action plan and how to outline the activities and the resources required to help your community achieve value for its vision;
- how to equip communities with the relevant capacity to build their community roadmap for a clear view of their actions, responsible actors and resources.
Mapping of the (chapter 3.1.4) there are four topics grouped by Drive, Steer, Build, Manage and by "senior and middle management", "core group", "all members", "community manager" by triplets.
The diagonal serving Ideate & Asses in Supply-Drive.
Consolidated into: Stakeholders for drive and PortfolioPlan for steer.
The functionalty for Build and manage going into several fractals.
👐 The governance of safety for information systems is Volatile, Uncertain, Complex and Ambigious.
| Confidentiality | Integrity | Availablity | Impact Engagement |
| High | High | High | Co-create & consult - CSO |
| High | High | Low | Co-create & consult - CDO |
| High | Low | High | Co-create & consult - ? |
| High | Low | Low | Co-create & consult - DPO |
| Low | High | High | ? |
| Low | High | Low | ? |
| Low | Low | High | ? |
| Low | Low | Low | Monitor passively - ? |
See right side.
For all kind of safety requitements the interactions to stakeholders are classified using a dual-axis matrix.
💣 There are weird gaps, a classic:
- CSO (Chief security officer) deals with the CIA triad
- CDO (Chief data officer) deals with integrity and PII
- DPO (Data protection office) with PII
There is no overall coverage for all possible options.
The only way out of this dilemma is have the CSO CDO DPO as advisory roles and the accountability responsibility of functionality and safety shared in the same role/task.
⟲ AK-2.3.4 Concept: Functionality instantiations safety missions
Retrospective for Functionality and Safety
Issues in the concept model for a product/service to solve:
❶ The duality functionality-safety are seen as parallel structure—two tracks that coexist—rather than a dynamic tension that must be choreographed at every transformation step.
👉🏾 Accountability Responsibility of functionality-safety should be shared in the same role/task.
❷ Other words are used in the top-down and bottom-up mindset although the intention is the same.
❸ That usage of different words happens for both inseparable contexts functionality and safety.
⏳ These four sets should be aligned in concept models.
Functionality:
- Technology : Direct ⇆ Determine ⇆ Development ⇆ Design ⇆ Diagnose ⇆ Data
- Administration: Mission Fit ⇄ Transforms ⇄ Boundaries ⇄ Lifecycle ⇄ Monitoring ⇄ Performance
Safety:
- Technology: Demarcation ⇆ Deny ⇆ Delay ⇆ Deter ⇆ Detect ⇆ Defend
- Administration: Responsibility ⇄ Dependencies ⇄ Constraints ⇄ Risks Monitoring ⇄ Mission Fit
👉🏾 What is missing:
- Explicit choreography between functionality and safety. Transformations don’t declare how safety constrains or enables functionality.
- A shared recursion logic, “Which” decisions don’t yet embed safety trade-offs or fallback paths.
- Dual-role dashboards, System-2 oversight, is implied but not visualized across both dimensions.
- In maturity alignment the Safety missions aren’t phased alongside functionality evolution.
❓ Why all this effort?
What is the diffference to classic project management e.g. Prince2?
- Zarf operates at a semantic modeling level, while PRINCE2 is procedural and operational.
- Zarf supports recursive modeling and fractal instantiation; PRINCE2 is linear and phase-based.
- Zarf embeds safety, wealth, fame, honor as systemic drivers; PRINCE2 does not.
- Zarf supports multi-cell transformations with System-2 coordination; PRINCE2 assumes a single project flow, fixed in stages (waterfall).
❓ What about the strange dulatiy in stakeholder roles?
- The operational execution: <discipline>:StakeHolder<:M/E/V/C>:_xxx
- The policy decisions are: <discipline>:StakeHolder<:S/I/A/R>:_xxx
There are more types but these are the ones for operations and cahnge.
⌛ Reframing the Duality Functionality vs Safety:
| Aspect | Functionality (Creation) | Safety (Constraint) | Integration Logic |
| Intent | Deliver capability, value, and mission fit | Preserve trust, legitimacy, and systemic integrity | Every capability must declare its safety envelope |
| Transformation | “Which” option is chosen to fulfill purpose | “When” and “What if” define fallback and exception paths | Recursive “Which” must include safety trade-offs |
| Time-Slice | Active in Now/Near Future instantiations | Governs Far Future implications and rollback logic | Time-slice must declare convergence and safety maturity |
| Stakeholder | Constructor, Operator, Beneficiary | Validator, Custodian, System-2 Coordinator | Role-flow must include dual accountability |
| Metrics | Performance, usability, mission success | Risk containment, exception frequency, trust score | Dashboards must show both dimensions side-by-side |
| Governance | Agile, adaptive, outcome-driven | Auditable, bounded, exception-aware | System-2 must orchestrate both flows in tandem |
👉🏾 Using a dynamic system is changing the old approach of delivering static documents.
Product/service isn’t just a deliverable, it’s a semantic construct that bridges functionality, value, and stakeholder resonance across abstraction layers.
AK-2.4 Purposeful & safe working environments
Using and changing systems are several levels of abstraction.
Technology used for transformations & information materialisations are volatile subjects by many options in a complex world.
Challenges for the Enterprise concepts:
- Concepts using maintaining creating platforms: how-runtime, where-deploy, who-operators, when-lifecycle.
- Domain: R (Functioning) & S (Control)& I (Influence) 💣 tensions.
governance for serving the purpose avoiding unwanted effects.
- Owner: Platform/Cloud Ops + Platform Safety Guardian.
⟲ AK-2.4.1 Platform constructs: technology components abstractions
Product/service ownership to get first focus
Product/service ownership is not a static reference, it serves as semantic anchor within the ZARF multidimensional grid in supporting clarity, traceability, and transformation across abstraction layers and interrogative flows.
⏳ Product/service ownership:
- defines the semantic boundaries for valid transformations, semantic contract between roles and systems.
E.g. only certain roles are responsible for specific actions.
- information inherits and propagates governance constraints, a recursion anchor for “Which” decisions at every abstraction level.
E.g. product/service delviery promises and quality rules.
- encodes dependency logic, boundary object across flows (engineering, administration, delivery, supply).
E.g. a products/services must get created before validated into deliveries.
- shapes external identity and trust, a legitimacy enabler, aligning internal structure with external expectations (safety, wealth, fame, honor).
E.g. how a system presents its catalog, roles, or services to the outside world.
Product/service ownership is not just a title but is about interactions, habits and behavior.
Less abstract:
| 6w1h | Master data reference | Example |
| What: | Promises Product/Service external deliveries | Found in the portfolio & innovations. |
| How: | Specfication schemes using taxonomies | Using & creating Instructions for constructions. |
| Where: | Location hierarchies, jurisdiction zones | Warehouse locations, Legal agreements. |
| Who: | Role definitions, organizational units | Inventor,Constructor - Development, Operations. |
| When: | Temporal anchors, lifecycle states | Product/service valid-from dates, Maturity stages. |
| Which: | Decision criteria, disambiguation logic | Product eligibility rules, usability, aplicability. |
Each of these is instantiated across abstraction layers—from conceptual (e.g. stakeholder roles) to operational (e.g. user accounts, cost centers).
⌛ Example for a role within managing the portfolio:
- Domain - System Logic : Role = "Functionality & Functioning - Constructor"
Alternative titles: Chief Engineer, Chief Product Officer, Product Owner.
- Semantic Function : Ensures product/service integrity for external result deliveries by all involved transformations.
- Governance: Must be assigned before a "Which/Why" decision of the product functionality & functioning is finalized.
- Interaction: Feeds into domains:
- "Master Data - How": Ensuring system integrity in concept models, category & risk.
- "System Logic - What": task design for differentiate supply external & internal.
- “Technology - What”: choices & preferences for platforms to use.
💣 The word "product-owner" (scrum: component tool) results to: uncertainty & ambiguities.
DevOps: DevOps Decision Compass
Site Reliability Engineering (SRE) and DevOps are two methodologies that aim to improve the software development and operations process, but they have distinct focuses and approaches.
Key Principles and Focus
- DevOps, on the other hand, focuses on the end-to-end application lifecycle, from development to deployment and maintenance.
It aims to break down silos between development and operations teams, fostering a collaborative environment. DevOps emphasizes continuous integration and continuous delivery (CI/CD), automation, and a culture of shared responsibility.
- SRE primarily focuses on the reliability and stability of the production environment.
It aims to ensure that systems are scalable, reliable, and can handle failures gracefully.
SRE uses metrics like Service Level Indicators (SLIs) to track system performance and reliability.
The approach is systematic and data-driven, emphasizing automation to reduce manual intervention and improve predictability.
Goals in states and flows a selection
For states:
| Organization | Strategy | Technology | Process |
| Responsive | Focused | Robust | Flexible |
| Technology governance | Process Governance | Technology performance | Process performance |
For transformations:
| Run / Execute -Monitor | Analyse | Design | Implement |
| Business Performance | Business governance | Information architecture | Information engineering |
| Values fiance & ethical | measurements | System components | Platform tools |
⟲ AK-2.4.2 Concept Platforms: SRE, DevOps - Technology decisions
Mapping of abstraction semantic BRules
The abstraction-axis is how the meaning is perceived by another perspective in the involved tasks.
The combination of both axis context and abstraction should cover a specific discipline.
For three disciplines related to the IS (Information Systems) domain going into more details, the are:
- SRE, DevOps - decisions (Technology)
Note: Roles are part of stakeholders. This is about details in decisions doing DevOps.
| ViSM | Semantic | Devops decisions | SRE decisions |
| system-1 | Context | Decision node | Decision node |
| system-3 | Concept | Trigger / Event | Trigger / Event |
| system-4 | System Logic | Agent / Actor | Agent / Actor |
| system-5 | Technology | Outcome / impact | Outcome / impact |
| system-2 | Components | Feedback loop | Feedback loop |
| universe | Instance | Governance | Governance |
Questions that help structure SRE, DevOps - decisions understanding across context layers.
Simple questions:
| Zarf | decision role alginment focus and purpose |
| Definition | What is the nature of the decision being made? |
| Category | How is the decision structured and executed? |
| Class | Where does the decision apply within the system landscape? |
| Identity | Who is responsible for making or authorizing the decision? |
| Timing | When is the decision triggered or required? |
| Distinctive | Which options or paths are available, and what trade-offs exist? |
Questions that help structure SRE, DevOps - decisions understanding in enabling role clarity, decision traceability, and governance alignment.
Logical detailed questions:
| Zarf | Decisions alignment focus |
| Definition | Define key DevOps concepts: pipeline, deployment, incident, rollback, CI/CD. Clarify what each term means in context. |
| Category | Categorize decisions by type: automated vs manual, reactive vs proactive, tactical vs strategic. Reveals automation level, decision flow, and procedural logic—manual vs CI/CD pipeline, scripted vs orchestrated. |
| Class | Classify decisions by domain: infrastructure, application, security, compliance. Ensuring correct scope and impact zone. Map to layers (e.g., frontend/backend, cloud/on-prem). |
| Identity | Identify decision agents: developer, SRE, release manager, product owner. Assign roles and responsibilities. Enabling traceability and escalation. |
| Timing | Aligns timing—pre-deploy, post-incident, sprint planning—with lifecycle and event logic when stakeholders act—decision timing, escalation paths, lifecycle involvement. |
| Distinctive | Enables choice modeling—rollback vs patch, hotfix vs wait—embedding scenario logic and recursive evaluation. decision timing: pre-deploy, post-deploy, during incident, in sprint planning. Use event triggers and lifecycle stages. |
SER, DevOps - decisions Alignment 6*6 Matrix: Semantic Mapping
Questions that help structure SER, DevOps - decisions understanding across context layers & abstraction layers.
❶ Alignment by What en How:
| What (define) | How (Categorize) |
| Decision node | What is the decision (e.g., deploy, rollback)? | How is it structured (manual/automated)? |
| Trigger / Event | What initiates the decision? | How is the trigger categorized (alert, commit)? |
| Agent / Actor | What is the agent’s role? | How is the agent grouped (team, persona)? |
| Outcome / impact | What is the expected result? | How is success measured? |
| Feedback loop | What feedback is generated? | How is it structured (metrics, logs)? |
| Governance | What policies apply? | How are rules enforced? |
❷ Alignment by Where en Who:
| Where (Classify) | Who (Name) |
| Decision node | Where does it apply (infra/app/security)? | Who makes it (Dev, SRE, PO)? |
| Trigger / Event | Where does it originate (monitoring, CI)? | Who initiates it (system, person)? |
| Agent / Actor | Where is the agent located (on-prem/cloud)? | Who is the agent (name, ID)? |
| Outcome / impact | Where does impact manifest (user, system)? | Who is affected? |
| Feedback loop | Where is it routed (dashboard, alerting)? | Who receives it? |
| Governance | Where are boundaries set? | Who approves or escalates? |
❸ Alignment by When en Which:
| When (Time) | Which (Distinguish) |
| Decision node | When is it triggered (pre/post deploy)? | Which options are viable (rollback vs patch)? |
| Trigger / Event | When does it occur (real-time, scheduled)? | Which triggers are critical vs optional? |
| Agent / Actor | When is the agent active? | Which agents overlap or conflict? |
| Outcome / impact | When is impact visible? | Which outcomes are acceptable? |
| Feedback loop | When is it reviewed? | Which feedback loops are closed/open? |
| Governance | When is governance applied? | Which rules are flexible vs strict? |
⟲ AK-2.4.3 Platform constructs: technology adjustments abstractions
Example TIS, part of Theory of constraints
five-state-model (Kevin Kohls 2025)
In the Throughput Improvement System (TIS), we use a simple but powerful lens: every workstation can only be in five states: Running, Down, Blocked, Starved, or Off.
These states can be programmed into a PLC or tracked with phone video. Each time a part is made, the counter increments and the Run cycle continues. ...
With TIS, we have sonar. We can see constraints before they hit and avoiding problems is far cheaper than experiencing them.
Why it matters is for metrics:
- Stand Alone Throughput (SAT): the time in Run ? Down divided by parts produced.
- Mean Time Between Stops (MTBS)
- Average Cycle Time
- Mean Time To Resume (MTTR)
Optimizing just a machine component in the flow doesn't improve automagically the system as a whole.
Understanding the interaction of the component in the system is a pre requisite for choosing where efforts will have positive seen effects.
Flow functionality in ordered internal states horizontal axis:
- What ➡ Off Unclear by unknown service planning
- How ➡ (On) in order
- Where ➡ (On) Down Look for the problem to solve
- Who ➡ (On) Blocked Somebody is expected to react for a solution by decisions.
- When ➡ (On) in disorder Needing maintenance, could be decided: temporary accepted.
- Which ➡ (On) Starved Unclear by unknown flow planning
Example Smed - Quick Changeover
Quick Changeover Basics - SMED (C.Roser 2014)
Changing the troughput.
One popular approach to battle waste is to streamline changeovers.
Changing machines from one set-up to another is often a time-consuming exercise.
Hence, in lean manufacturing, reducing changeover times is a well-known method for improving efficiency.
Also known as quick changeover or single minute exchange of die (SMED). ...
As with any improvement project, the first question you should ask yourself is, "Is this my biggest problem right now?".
As always, you should have an overview of the problems you are facing and have them prioritized.
Flow functionality in ordered internal states horizontal axis:
- What ➡ Measure: Changeover Times
- How ➡Classify: Identify Internal and External Elements
- Where ➡Path Reorder: Move As Many Elements as possible to External
- Who ➡Path Overall: Shorten Elements External and internal.
Depedencies for the change over at the workers
- When ➡Path Stopped: Shorten Internal Elements
Depedencies in the change over for the process
- Which ➡Capability: Standardize and Maintain New Procedure
Because I see the axis as ordered but the activities in nonlinearity based on existing knowledge, it makes more sense to focus on the worker interest in that ordering.
Example TIS Optimizing by avoiding wat is seen as unwanted
The five state model (K.Kohls) continued.
By projecting an improved MTBS or MTTR and entering those into simulation, we unlock one of the most valuable insights of the Throughput Improvement Process (TIP): the next bottleneck.
With clear states, we stop debating and start improving.
Added is the state "Off", but I'm missing the state the machine is running but creating too many defects.
A simulation is a indication the whole system is evaluated using a model of the system. The goal of the simulations is finding what is holding up in the speed of flow system.
Focus on machine states:
- Off ➡Unknown service Machine is turned off; no data collected. 🎭
- (On) in order ➡In service Running Possible actively making parts
- (On) Down ➡Failing service Something is wrong; the machine should be running but isn't.
- (On) Blocked ➡Failing service Nowhere to put the next part.
- (On) in disorder ➡Failing service Too many defects are created by the machine.
- (On) Starved ➡Unknown service No parts available to work on. 🎭
👁 💡 These "failing service" states are simply to represent in status flags.
For alerts at a higher level only a summary alert signal is sufficient.
👁 💡 Measuring the quality seeing defects in created products needs an additional measurement that is possible not part of the machine.
👁 ➡ The "unknown service" states are needing additional information before it is clear it is about an alert or normal wanted condition.
When all planned products are created there is no reason to create more of those. Starvation is in that case planned.
Example Smed - Quick Changeover
The SMED methodology (C.Roser) continued.
Before you start measuring, you should make sure that you get the entire process measured, not just part of it.
The changeover itself starts after the last part produced at full speed and ends with the first part produced at full speed.
It is easy to overlook, for example, times where the machine is running already but the operator still adjusts the settings and hence the machine is slower than planned.
Whenever you measure times on the shop floor, or even take video, you should inform the workers and their representatives and get their agreement. ...
If the workers disagree with you measuring them, they can easily mess up your measurements by working extra slow.
In many cases, you wouldn't notice if they added additional steps to the procedure.
- Measure: ➡ a list of steps including an average time to do those
- Classify: ➡ what can be done without stopping and what needs a stopped machine>
- Path Reorder: ➡ to minimize the stopped time by ordering
- Path Overall: ➡ to improve by minimizing the workers activities.
- Path Stopped: ➡ the goal in improving the flow of the process.
- Capability: ➡ Knowledge assurement, specifying, documenting, training.
The last step is the most difficult one and the most frequently forgotten one.
It is not enough to do a changeover quickly once; you have to do it quickly every time.
So you need to fix the new standard, document it, train all relevant workers in the new standard, and do a process confirmation.
Any standard not maintained that way will be soon lost.
👐 The governance of safety for information systems is Volatile, Uncertain, Complex and Ambigious.
| Confidentiality | Integrity | Availablity | Impact Engagement |
| High | High | High | Co-create & consult - CSO |
| High | High | Low | Co-create & consult - CDO |
| High | Low | High | Co-create & consult - ? |
| High | Low | Low | Co-create & consult - DPO |
| Low | High | High | ? |
| Low | High | Low | ? |
| Low | Low | High | ? |
| Low | Low | Low | Monitor passively - ? |
See right side.
For all kind of safety requitements the interactions to stakeholders are classified using a dual-axis matrix.
💣 There are weird gaps, a classic:
- CSO (Chief security officer) deals with the CIA triad
- CDO (Chief data officer) deals with integrity and PII
- DPO (Data protection office) with PII
There is no overall coverage for all possible options.
The only way out of this dilemma is have the CSO CDO DPO as advisory roles and the accountability responsibility of functionality and safety shared in the same role/task.
⟲ AK-2.4.4 Concept Platforms: values stream - Technology decisions
Retrospective for Functionality and Safety
Issues in the concept model for a product/service to solve:
❶ The duality functionality-safety are seen as parallel structure—two tracks that coexist—rather than a dynamic tension that must be choreographed at every transformation step.
👉🏾 Accountability Responsibility of functionality-safety should be shared in the same role/task.
❷ Other words are used in the top-down and bottom-up mindset although the intention is the same.
❸ That usage of different words happens for both inseparable contexts functionality and safety.
⏳ These four sets should be aligned in concept models.
Functionality:
- Technology : Direct ⇆ Determine ⇆ Development ⇆ Design ⇆ Diagnose ⇆ Data
- Administration: Mission Fit ⇄ Transforms ⇄ Boundaries ⇄ Lifecycle ⇄ Monitoring ⇄ Performance
Safety:
- Technology: Demarcation ⇆ Deny ⇆ Delay ⇆ Deter ⇆ Detect ⇆ Defend
- Administration: Responsibility ⇄ Dependencies ⇄ Constraints ⇄ Risks Monitoring ⇄ Mission Fit
👉🏾 What is missing:
- Explicit choreography between functionality and safety. Transformations don’t declare how safety constrains or enables functionality.
- A shared recursion logic, “Which” decisions don’t yet embed safety trade-offs or fallback paths.
- Dual-role dashboards, System-2 oversight, is implied but not visualized across both dimensions.
- In maturity alignment the Safety missions aren’t phased alongside functionality evolution.
❓ Why all this effort?
What is the diffference to classic project management e.g. Prince2?
- Zarf operates at a semantic modeling level, while PRINCE2 is procedural and operational.
- Zarf supports recursive modeling and fractal instantiation; PRINCE2 is linear and phase-based.
- Zarf embeds safety, wealth, fame, honor as systemic drivers; PRINCE2 does not.
- Zarf supports multi-cell transformations with System-2 coordination; PRINCE2 assumes a single project flow, fixed in stages (waterfall).
❓ What about the strange duality in stakeholder roles?
- The operational execution: <discipline>:StakeHolder<:M/E/V/C>:_xxx
- The policy decisions are: <discipline>:StakeHolder<:S/I/A/R>:_xxx
There are more types but these are the ones for operations and cahnge.
⌛ Reframing the Duality Functionality vs Safety:
| Aspect | Functionality (Creation) | Safety (Constraint) | Integration Logic |
| Intent | Deliver capability, value, and mission fit | Preserve trust, legitimacy, and systemic integrity | Every capability must declare its safety envelope |
| Transformation | “Which” option is chosen to fulfill purpose | “When” and “What if” define fallback and exception paths | Recursive “Which” must include safety trade-offs |
| Time-Slice | Active in Now/Near Future instantiations | Governs Far Future implications and rollback logic | Time-slice must declare convergence and safety maturity |
| Stakeholder | Constructor, Operator, Beneficiary | Validator, Custodian, System-2 Coordinator | Role-flow must include dual accountability |
| Metrics | Performance, usability, mission success | Risk containment, exception frequency, trust score | Dashboards must show both dimensions side-by-side |
| Governance | Agile, adaptive, outcome-driven | Auditable, bounded, exception-aware | System-2 must orchestrate both flows in tandem |
👉🏾 Using a dynamic system is changing the old approach of delivering static documents.
Product/service isn’t just a deliverable, it’s a semantic construct that bridges functionality, value, and stakeholder resonance across abstraction layers.
AK-2.5 System as a whole resource alignments
When systems are showing dynamics, there must be an effective closed-loop, good-regulator in place for changes.
The dynamic, interactions are changing components and the whole.
Challenges at Enterprise concepts:
- good-regulators: these are systems on their own. By nature in complex systems predictable within the chaotic behaviour.
- Domain: A (Adaption) Be aware: 💣 vertical and horizontal tensions for scope and adadption limits.
- Owner: Chief engineer - Architect + Curator, Executive board.
⟲ AK-2.5.1 Recognizing complexity by disperse fractals in systems
Connecting the 6w1h for stakeholders to platforms
In the business as usual (BAU) it is hard to get into a perpective of the supersystem of the system.
The connection to 6w1h
| BAU Conceptuals | 6w1h | description |
| AK-2.1 Defining | What | the words language is, stakerholders are. |
| AK-2.2 Construction | How | the system should work in fucntionality |
| AK-2.3 Materialisation | Where | the system gets used to fucntioning |
BAU: business as usual, but what is usual in the who?
A mind-set switch to abandon the confusing idea: it should only be about persons.
| BAU Instance | 6w1h | description |
AK-2.4 Platform Embedding | Who | Acceptable for the who is a role/taks for wor done by: 👁 machines, 👁 platforms, 👁 AI. |
BAU: business as usual.
| BAU Governance | 6w1h | description |
| AK-2.5 Closed-loop | When | A confusing question for a good-regulator is: 👁 which one is the most simplistic and does what it should do. |
| AK-2.6 Outcomes, results | How | the system should work in fucntionality |
Goals in states and flows a selection
The Holistic Approach: Combining BPM with Value and Performance Management, Enterprise Architecture, Governance, and SOA (M von Rosing, R Eijpe, C. Laar, A Rosneberg, S Kuhlmann - december 2010).
Over the past few years, many initiatives have come to life for SAP customers:
Initiatives from service-oriented architecture (SOA), business process management (BPM), value management (VM), enterprise architecture (EA), and with this not only the technology architecture and information architecture, but also the business architecture.
...
The key distinction for BPM as a discipline is added focus on flexible and dynamic process design and process orchestration and automation through IT enablement.
In addition to reduced costs through continued improve- ment and automation, BPM also provides the foundation for converged and agile business and IT responsiveness and is the key to applying the principles discussed in this chapter.
Figure 4.8 shows these principles from the process management lifecycle perspective in integrating business modeling, process modeling, gover- nance, ownership, business value, and business performance.
The orientation in the figure is not what I am used to but having done the orientation adjustment more often this figure got my attention.
It is chaotic disordered at the outer part but nicely ordered in the fractals in the centre.
Zarf Relevant concepts in considerations
Example Application
Let’s say the “Which–Technology” cell (design choices for tech stack) is recursively explored across multiple platforms.
Once the viable options are narrowed to a few with clear trade-offs, further recursion (e.g., down to chipset specs) may be unnecessary.
At this point:
- The cell is marked as atomic
- It may be grouped into a domain like “Platform Strategy”
- All upstream and downstream dependencies are preserved
- The consolidation is documented for governance and future audits
Dashboard Templates by Role:
| Stakeholder Role | Ordering Used             | Dashboard Focus Areas |
Engineer / Architect | What → How → Where → Who → When → Which | Technical structure, process flow, implementation choices |
Administrator / Regulator | Which → When → Who → Where → How → What | Governance, timing, accountability, compliance |
Citizen / End User | Which → When → Who → What → How → Where | Identity, service delivery, trust, usability |
Vendor / Supplier | Where → How → What → Which → When → Who | Location, product, integration, timing, stakeholder roles |
Planner / Strategist | Who → When → Which → Where → How → What | Strategic roles, future planning, decision geography |
The sense in variations for the ordering axis 6w1h
That isn’t just listing variations of the 6W1H axis—it’s revealing how different disciplines, perspectives, and system roles reorder the same interrogatives to reflect their priorities, logic, and worldview.
This is a fractal insight: the same building blocks (What, How, Where, Who, When, Which) are reused, but their ordering changes depending on context.
Why This Is Powerful:
- Fractal Modeling: You can apply the same 6W1H logic recursively, but the ordering adapts to the domain.
- Perspective Awareness: Helps avoid miscommunication between disciplines (e.g., engineers vs. administrators).
- Diagonal Sensitivity: Changing the order affects what appears on the diagonals—i.e., what’s considered “central” or “critical.”
- Conflict Resolution: Many system conflicts arise from implicit ordering assumptions. Making them explicit helps resolve ambiguity.
Those variations turn the 6×6 reference frame into a multi-perspective, recursive, decision-aware system.
It’s not just a matrix—it’s a lens that adapts to the viewer.
| Perspective | Focus - most visible |
| Engineering | Technical structure, process, and control |
| Administration | Governance, timing, accountability |
| Internal Power, Trading | Roles, timing, decision-making |
| External Power, Trading | Location, function, product, stakeholder |
| Technology/Machines | Decision logic, timing, execution |
| Operations/Processes | Role-driven flow, spatial layout, repetition |
| People/Service | Identity, timing, responsibility, delivery |
| Planning/Structure | Strategic roles, timing, decision geography |
Imagine the ZARF grid as a lens. Each ordering tilts the lens, changing what’s in focus:
- Engineering sees the “What–Technology” and “How–Component” cells as central.
- Administration sees “Which–Concept” and “When–Instance” as critical.
- External Power, justice, trading sees the “When–Component” and “Who–Instance” as most visible.
- Internal Power, justice, trading sees the “Where–Component” and “How–Instance” as the face of the system.
For the Why to start there are the How's and When's that matters most.
The sense in variations for the ordering axis 6w1h
Example in Enterprise Design , Imagine designing a data governance system:
- What: Data assets, metadata, lineage
- How: Classification, access control, retention policies
- Where: Cloud zones, on-prem clusters
- Who: Data stewards, compliance officers
- When: Real-time vs batch enforcement
- Which: Which governance model balances agility, compliance, and cost?
This final "Which" forces the team to choose between centralized vs federated
CATWOE is an acronym that stands for:
Customers - Actors - Transformation process - World view - Owners - Environmental
constraints. It's a simple checklist to find solutions to problems.
TASCOI is referred to as a method of naming the system, and provides a taxonomy for the persons or organisations who control and influence the Transformation.
Transformation Actors, Suppliers, Customers, Owners and Interveners
⟲ AK-2.5.2 Creation of fractals in a system, autonomous growth
Adding one topic, getting two additionals
Growth in a blue ocean, 1,2,4,8,16
Consolidating topics but acknowledge the 6*6 grid
Consolidating topics but acknowledge the 6*6 grid
⟲ AK-2.5.3 Absorbing another system, growth getting variation
s?
Nine planes (Mike Cardus 2015)
Routine causes of psychological inertia:
- Having a fixed vision (or model) of the solution or root cause.
- False assumptions (trusting the data).
- Language that is a strong carrier of psychological inertia. Specific terminology carries psychological inertia.
- Experience, expertise and reliance upon previous results.
- Limited knowledge, hidden resources or mechanisms.
- Inflexibility (model worship; trying to prove a specific theory, stubbornness).
- Using the same strategy. Keep thinking the same way and you will continue to get the same result.
- Rushing to a solution – incomplete thinking.
In a figure:
see right side.
Two cycles strategy and operations are connected by defining systems.
Retrospective for Stakeholder and Portfolio/Plan
The understanding continuum for enterprises by concepts resulted in the question who the stakeholders are, what they want to be solved or improved.
That should give an answer for the
Why of a follow-up in activities. The why stated by a vison that is transformed into missions.
⏳
For the concept modelling into a data model that is:
- ZARF_XPOS: Defining the role of stakeholders in the social interaction context.
- The suggestion box, backlog concerns (jabes): for a shared intention of stakeholders.
This is a dynamic process in interactions and dynamic during the complete life-cycle of the product/service.
- ZARF_VIRU: The way decsions are mode should have closed loop controls in a shared set in policies.
- The suggestion box, backlog concerns (jabes): for openess in trust and auditability for what was stated in time by who.
👉🏾 Using a dynamic system is changing the old approach of delivering static documents.
⌛
Having defined missions, the what (input) for fractals wirh a which (result), fractal are to solve the How, Where, Who, When in another context.
Each fractal can define a partial aspects of the bigger whole or using the what (input) amd which (result) of the whole.
The simple structure by ZARF_STRC is not broken but getting complicated by the nature of fractals.
It is the neurology (ZARF_VIRU) that should hold it together as a whole.
- How: Functionality/Safety for the product/service is about transformations (dynamics).
- Where:Functioning/Safety for the product/service is about visible measurable states (Static).
- Who: Platform/Safety is about tooling's for achieving functionality & functioning.
- When: Alignment for the system Everything should fit together(which/why), delivered by expectations (when). How fractals are being created stopped annihilated or detached is the complication in dynamic complexity.
Closed loops are not static but dynamic by nature.
👉🏾 Using a dynamic system is changing the old approach of delivering static documents.
Product/service isn’t just a deliverable—it’s a semantic construct that bridges functionality, value, and stakeholder resonance across abstraction layers.
The goal and the flow stability
kolbs-learning-cycle ()
Thinking about thinking
Opening the Box by Jan de Visch (SCIO NL KNVI presentation dutch language)
J de Visch site
Was written to make systems thinking accessible and engaging through a unique dialogue format.
It aims to challenge conventional thinking, encourage critical exploration, and provide a practical tool for opening conversations that lead to deeper understanding and transformative change.
It also addresses the limitations of traditional, mechanistic approaches in today’s complex business environment.
Exploration of human constructs: It explores the reality of organizations as human constructs, and the importance of multiple realities.
It’s a tool for fostering transformative conversations and deepening comprehension of living systems dynamics.
Four layers of systems thinking:
- Parts and Wholes
It emphasizes that no element exists in isolation—every part contributes to a larger whole.
Ask: How do individual components interact to shape the system’s behavior?
- Nascent Developmentsometimes referred to as Emergent Development.
Focuses on how systems evolve over time.
It’s about spotting patterns of growth, decay, or transformation that aren’t immediately obvious.
Encourages us to look for potential—what’s emerging beneath the surface.
- Coherence explores the internal logic or “fit” within a system.
That what makes a system resilient and meaningful.
Ask: Do the parts align with the system’s purpose and values?
- Metamorphosis
It’s about radical change—when a system shifts into a completely new form.
Often triggered by crises, breakthroughs, or paradigm shifts.
Example: The shift from fossil fuels to renewable energy isn’t just a technical change—it’s a metamorphosis of societal priorities.
These layers aren’t steps in a process—they’re lenses you can use to interpret and influence systems at any level.
Mapping of abstraction semantic for using BRules
ZARF in public trust, recovery across Layers & Time Slices
Crisis Scenario: Digital service outage during benefits time window.
Layer Interactions:
- STRC (Anatomy) maps the structural impact and time horizon of the failure.
- INTR (Physiology) governs how cells interact to contain and correct the issue.
- VIRU (Neurology) ensures governance, logs actions, and orchestrates recovery.
- XPOS (Sociology) manages the social narrative, cultural fit, and trust restoration.
Now (Immediate Response):
| Layer | stage | |
| ---- | What | An event to act for in a crisis response model |
| STRC | How | Identify affected cells: What–Component, Who–Instance, When–Technology |
| INTR | Where | Trigger horizontal updates: Who–Instance ↔ When–Component |
| ---- | Which | selected prepared crisis response model |
| VIRU | When | Activate exception path: rollback What–Component, notify Who–Instance |
| XPOS | Who | Reassert identity: “Citizen-first, transparent, accountable” |
Near Future (Stabilization):
| Layer | stage | |
| ---- | What | Root cause analysis |
| STRC | How | Redesign How–Logic and Where–Technology to prevent recurrence |
| INTR | Where | Consolidate 2×2: What–Technology + How–Technology → “Recovery Engine” |
| ---- | Which | Knowledge consolidation root cause(s) |
| VIRU | When | Orchestrate composite recovery via System-2 cell, log all actions |
| XPOS | Who | Adapt messaging and behavior to cultural expectations, engage stakeholders |
Far Future (Resilience & Renewal):
| Layer | stage | |
| ---- | What | Concept adjustments in correcting root causes |
| STRC | How | Reframe Which–Concept to include resilience as a design goal |
| INTR | Where | Consolidate 3×3: Which–Concept, Who–Concept, When–Concept → “Trust Cluster” |
| ---- | Which | Specification adjustments covering the root cause corrections |
| VIRU | When | Embed feedback loops into How–Logic and Which–Context |
| XPOS | Who | Publish postmortem, launch listening sessions, reinforce legitimacy |
⟲ AK-2.5.4 Dispatching internal systems, collaborations of systems
Maturity absorption BAU (Business As Usual)
| BAU AK-2.1 Concepts Defining | AK-2.2 Concepts Construction | AK-2.3 Concepts Materialisation | AK-2.4 Platform Embedding |
| AK-2.1.1 Shared language for understanding in concepts | AK-2.2.1 Semantic concepts and abstractions | AK-2.3.1 Purpose logic transformed | AK-2.4.1 Platform constructs reflect intent |
| AK-2.1.2 Purpose in stakeholder intent external/internal | AK-2.2.2 Roles, tasks, scope visions | AK-2.3.2 Missions aligned to functionality | AK-2.4.2 Prioritized in platform decisions |
| AK-2.1.3 Shared language for understanding in methodologies | AK-2.2.3 Purpose, goals, methodologies | AK-2.3.3 Safety logic transformed | AK-2.4.3 Enforced in platform adjustments |
| AK-2.1.4 Purpose in by missions in portfolio (specifications) | AK-2.2.4 Portfolio, budget, goal visions | AK-2.3.4 Safety missions operationalized | AK-2.4.4 Validated in value stream decisions |
Zarf Relevant concepts in considerations
Risks, Gaps & Ambiguities (AK-1):
- Complexity & overhead: The model is ambitious and multi-dimensional. Without careful scoping, it can become overwhelming, hard to apply in real projects.
- Ambiguity & lack of concrete rules: While many principles are presented, some rules (how to move diagonally, recursion boundaries, orchestration) are expressed more aspirationally than operationally.
- Steep learning curve: It requires familiarity with systems theory, lean, Zachman, recursion, fractals. Teams without exposure may struggle.
- Risk of over-generalization: In trying to cover “all systems,” it may lose specificity for particular domains—details may have to be imposed externally.
- Value integration is subtle: Embedding human motivations (safety, fame, etc.) is powerful, but translating that into system constraints or design decisions may be tricky or subjective.
- Which vs Why trade-off: The replacement of “Why” with “Which” is philosophically interesting, but it may de-emphasize deeper purpose or normative grounding in favor of decision logic. Some domains still need a sense of why to anchor direction.
- Practical application / tooling missing: The page is conceptual; applying it in real community, organizational or software design may require additional templates, governance, tooling.
Negative actions in transformations
- Universe ➡ (What)
- (What) ➡ (How)
- (How) capability maps ➡ (Where)
- (Where) t ➡ (Who)
- (Who) ➡ (When)
- (When) ➡ (Which)
- (Which) Track your ideas ➡ Universe
Manage Conditions:
- (intentionally left empty)
This is where the Matrix lives. The challenge of the X-matrix is that only the half, three cell items of the complete line of six ordered cells is present.
There is a natural variation over all components by cells and transformations interactions between the cells.
AK-2.6 Maturity Learning systems & AI-LLM
When systems are showing dynamics the results outcomes are continuously changing.
They are never the same although within limits of deviations there is an acceptable conformity in similarities for usability.
Challenges at Enterprise concepts:
- Weil defined specifications: these are the result of systems that are building trust when there is aligned safety.
- Domain: (*) The system as a whole ware: 💣 vertical and horizontal tensions for scope and adaption limits.
- Owner: Governance board, Executive board.
⟲ AK-2.6.1 Resolving helpless by adding orientation awareness
Recognizing the issue of helpness
Not knowing in a context for what and how is a pattern often seen but seldom shared in openness.
❶
Stop Staring Over the Fence (K.Kohls 2025)
It’s tempting to look at your neighbor’s perfect garden and wonder why yours doesn’t look the same.
But if you’ve ever watched the master gardener at work, you know—those results took years, skill, and a goal that may not even match yours.
In business, it’s the same. Too many leaders look over the wall at the gardens of others: Toyota, Apple, Danaher, forgetting those systems were cultivated over decades.
Your first step isn’t to copy them; it’s to define your goal and find the constraint, often time, then focus every habit loop there.
Figure out a reachable goal:
- Design habits that reward progress, not comparison.
- ... because habits built on envy burn cortisol,
- habits built on purpose release dopamine! That’s what sustains effort.
👉🏾 The question is for what and how to get habits, culture, changed.
❷
Low-fidelity copying of methods while ignoring their principles. (Li-post Laksh Raghavan 2025) promoting a book: "Connecting the Dots... Reflections on The Toyota Production System"
Automation and Artificial Intelligence promise efficiency, but they also raise questions about jobs, ethics, and what improvement really means.
These are not new dilemmas.
The conditions that shaped TPS (Toyota Production System) such as resource constraints, global uncertainty, and rapid change are not so different from what organizations face now.
That is why these ideas remain powerful, provided we understand their intent.
A blind jump into a RCA root cause analysis, describing what is going in C&C.
There are two types of leaders!
- One is caught up in rituals / methods / tools / frameworks - "what" to do. They are fans of Scrum / Kanban / Spotify Model / Agile / Lean.
- The other thinks about the uniqueness of their context and truly chase the "Why" behind these ideas...
This means that they focus on continuously getting better at making maps of their territory. They then careful choose their methods.
👉🏾 The change question for habits, assumptions, not chasing the what but the why.
❸
The evolution of the language model (Bil Inmon 2025)
In 2002 the question came up – why are corporations using only 5% of their data for making 95% of their decisions? ...
Out of intellectual curiosity I sat down and started to deeply ponder this question.
The interesting thing was that once the BLM was built for an industry, the model applied to all companies engaged in that industry.
There was no need for the building of a separate BLM for all companies involved in an industry.
Generic BLM’s sufficed very nicely.
The business language model, BLM, had several unique components:
- The generic language model.
- The industry specific component.
The industry specific component vocabulary that was being disambiguated.
- The general business terms any large business would have.
These terms included accounting terms, finance terms, legal terms, and so forth.
- The fourth step in the evolution of the language model: the building of the BLM.
While an significant effort was required in the building, the BLM could still be built..
What is amazing is that the world is going through the same evolution today.
What is even more amazing is that the world insists on going through the evolution in a trial and error basis.
It is painful and slow to use trial and error as the teacher. It is also not smart.
👉🏾 The question is: change habits in knowledge management. Ignorance & amnesia are bad.
❹
From Ambiguity to Automation (Shumin Chen 2025) is about ASD-STE100 (Simplified Technical English).
Every major corporation today is investing heavily in Information Science, from advanced data analytics to Large Language Models (LLMs) and Generative AI.
The promise is transformation: faster insights, automated content, and seamless global operations.
But there is a critical vulnerability hiding within these investments: the quality of the input data.
The most profound challenge facing modern information systems is semantic drift, when the meaning of a concept changes across departments, regions (like India, Japan, or Europe), or even over time.
- A software system needs an ontology, a rigorous, explicit system of rules—to define exactly what something is.
- Human language, by contrast, thrives on synonyms and complex metaphors.
When humans write without discipline, they introduce this semantic chaos: they might use "fix," "fasten," "secure," or "attach" when they mean one precise action.
The machine sees four different terms, leading to data inconsistency and compromised machine reasoning.
Simplifying communication avoiding as much as possible ambiguity.
Simplified Technical English acts as a practical linguistic ontology for your human-generated content.
It systematically eliminates ambiguity by enforcing one core principle: One Concept, One Term, One Structure.
👉🏾 The change question in habits for knowledge management using a language that is understandable.
❓
With far more complexity in the understanding we should become better in orderinf and categorizing the topics gridwise in the art of understanding.
Reading the metaphor of Laksh Raghavan that "making maps of their territory" raises the question:
- Why is gridwise ordering in understanding missing?
- Where are the tools to navigate that are as simple like a compass?
- Where are maps drawn in a standard allowing usings tools like a compass easily?
The reply shows the uncertainty:
I'm not sure if lack of tools or technology or better ways of categorization is impeding our understanding.
A compass like tool for orientation and drawing maps
The associated citation by Laksh Raghavan gave a useful answer:
“… What we call 'progress' turns out to be a recognition of advances in technique, and has little to do with advance in understanding.
In short, we have become very good at following our technological nose, regardless of where we shall end up.
But understanding is a product of modeling, and the useful models change very little over the millennia."
(Stafford Beer)
✅💰 The SIAR visual is able to act as a tool for orientation. Knowing an orientation maps can be drawn.

➡ A materials, resources, flow from left to right adding value.
➡ clockwise cylce: push (I,II top), pull (IV,III bottom).
➡ Four different areas of interest, discipines types.
➡ Nine elements for interaction types, activities.
➡ Internal focus at the left, external at the right.
➡ Eight steps in the flow completed with two type of validations.
This orientation is used over and over again. Adjusting visuals to alignn this orientation.
The push (delivery), pull (control) generating the processing to set by a functioning good regulator.
The human system, sociality in systems by systems
The moral modalities framework (The Third System Foundation - 2019)
introduces a connection of society to systems thinking.
All human beings want to live a good life and share it with their nearest and dearest.
When life is difficult, it is easy to see what might make it better.
- If you are short of money, more money will make your life better.
- If you are being oppressed, life would be better if the oppression stopped.
But, when there is no obvious issue to be addressed, it is much harder to understand what would make your life better than it is now.
Since the 1950s, an enormous amount of research has been done on how our individual thinking is influenced by our cultural environment.
All agree on the following:
- Individual perception is very unreliable.
- Even when our individual perception is accurate, it can be overridden by the pressure to conform to the beliefs of those around us.
- Many will obey authorities even when we know it will lead to someone else suffering.
- Even when we know what we ought to do, we struggle to actually do it.
The Moral Modalities Framework adjusted into Zarf alignment six columns by headers:
| What | How | ⇄ | Where | Who | ⇄ | When | ⇄ | Which |
| system-1 | system-3 | ⇄ | system-4 | system-5 | ⇄ | system-2 | ⇄ | (universe) |
| | Unconditional care | ⇄ | Guardianship | Conditioned hierarchy | ⇄ | Exchange | ⇄ | Learning Network |
The columns represent different kinds of engagement, which we refer to as Moral Modalities.
“What” remains intentionally open—inviting context-specific instantiation.
| ContextxInstance | ... (what) | | Unconditional care (how) |
| Public-culture | Volatility, Uncertainty Complexity, Ambiguity | ⇄ | Civic compassion, inclusion |
| Public-purpose | ⇄ | Public infrastructure, Policy for vulnerable groups |
| Work purpose | ⇄ | Creative contribution, innovation |
| Working-guild | ⇄ | Mutual support, craftsmanship |
| Family-clan | ⇄ | Caregiving, emotional labor |
| Personal | ⇄ | Self-care, empathy |
If we confuse these modalities, or try to operate them for a different one, our lives go badly wrong.
| ContextxInstance | Guardianship (where) | | Conditioned hierarchy (who) |
| Public-culture | National identity, sovereignty | ⇄ | Prestige roles, elite hierarchies |
| Public-purpose | Institutional boundaries, legal justice | ⇄ | Bureaucratic authority, governance |
| Work purpose | Corporate mission, brand ethos | ⇄ | Org charts, management layers |
| Working-guild | Guild standards, codes | ⇄ | Seniority, apprenticeship |
| Family-clan | Family rules, traditions | ⇄ | Parental roles, sibling order |
| Personal | Personal boundaries | ⇄ | Habits, internalized norms |
Different social groups, at different stages of their evolution, specialise in different cells in the diagram, but a lack of balance will eventually lead to their failure to adapt to changing circumstances, when the advantages they may have once had will pass to some other social group.
| ContextxInstance | Exchange (when) | | Learning Network (which) |
| Public-culture | Global trade, Diplomacy | ⇄ | Cultural evolution, peer discourse |
| Public-purpose | Budget cycles, Negotiations | ⇄ | Think tanks, collaborative research |
| Work purpose | Contracts, KPIs, deliverables | ⇄ | Communities of practice, agile learning |
| Working-guild | Service exchange, partnerships | ⇄ | Peer mentoring, skill sharing |
| Family-clan | Household economics, reciprocity | ⇄ | Intergenerational learning, storytelling |
| Personal | Time management, personal deals | ⇄ | Self-reflection, growth mindset |
Trying to consolidate this into a 3*3 approach result into marvellous differences in interests but also show the tensions in what is consolidated by each 2*2 area.
🕳💣❌
Extraction of important stakeholders for involvement into systems is not obvious.
✅ The moralities reference is not a stand alone consideration, it a complex following systems thinking for the information age.
This is the highest supersystem humans are overall scattered essential components.
For the Purose Of the System Is What It Does there was no connected duality.
🎭 The duality of POSIWID = ROSIWIT (Resources Of the System Is What Is There).
Going beyond this assumes there is intended influence in the natural environment for resources.
⟲ AK-2.6.2 Habits and culture of supersystems into systems
The enterprise culture and its maturity
Analysing: "Diagnosing and Changing Organizational Culture: Based on the Competing Values Framework", (1999 Cameron, S. and Quinn R.E.), toe organisation types zarf alignment.
❸
Clan: the work-family model
| Dimension | Description of the culture |
| Definition | A flat, familial structure where interpersonal relationships and shared purpose thrive. Everyone knows each other, fostering a sense of belonging, mutual support, and collective identity. |
| Structure | Decentralized and non-hierarchical. Emphasizes collaboration, transparency, and strong internal cohesion. Communication flows freely across roles and levels. |
| Engagement | Employees feel valued, emotionally invested, and psychologically safe. The culture nurtures loyalty through empathy, recognition, and shared rituals. |
Leadership style | Leaders act as mentors, facilitators, and culture stewards. They prioritize personal development, trust-building, and inclusive decision-making. Authority is relational, not positional. |
Innovation & Risk | Creativity is welcomed through dialogue and co-creation, but disruptive risk-taking is tempered by a preference for consensus and relational harmony. |
| Best Fit | Effective when: mission-driven or values-based. Ideal for environments where human connection is a strategic asset: startups, nonprofits, education, hospitality and service sectors. |
Clan culture aligns to sociology and neurology layers.
Trust, legitimacy, and feedback loops dominate, a good fit when internal functioning must be emotionally and ethically coherent.
- Strong functioning: relational behavior, emotional bonds, shared rituals.
- Moderate functionality: purpose is implicit in values and community, not always formalized.
- High safety: trust boundaries, psychological safety, and internal legitimacy are prioritized over speed or disruption.
❹
Adhocracy: innovation unleashed
| Dimension | Description of the culture |
| Definition | A culture of bold experimentation and rapid iteration. Adhocracy thrives in uncertainty, where agility, creativity, and calculated risk-taking replace rigid protocols. It’s innovation in motion. |
| Structure | Fluid and adaptive. Hierarchies dissolve into project-based networks. Roles flex across initiatives, and success is measured by breakthrough outcomes—not process compliance. |
| Engagement | Energizing for autonomous thinkers and makers. Employees are empowered to challenge norms, pursue novel ideas, and shape their own paths within loosely defined boundaries. |
Leadership style | Leaders are catalysts—visionaries who provoke exploration and embrace ambiguity. They favor rapid prototyping over perfection, cultivate trust for experimentation, and learning. |
Innovation & Risk | Exceptionally high. Failure is reframed as feedback. The system rewards initiative, tolerates ambiguity, and celebrates disruptive thinking as a strategic asset. |
| Best Fit | Ideal for startups, R&D labs, tech ventures, and fast-paced product teams.
Effective in volatile or emerging markets. Speed & originality are competitive advantages. |
Adhocracy thrives in adaptive physiology and external facing anatomy.
It’s about transformation, not preservation, pushing the boundaries of functionality, often at the cost of safety.
- Undefined functioning: fluid, emergent, often chaotic, roles and behaviors shift rapidly.
- High functionality: purpose-driven innovation, agility, and exploration.
- Low safety: risk-taking is normalized, boundaries are porous, and failure is tolerated.
⚠ Safety is reframed as resilience.
❺
Hierarchy: the well-oiled machine
| Dimension | Description of the culture |
| Definition | A culture built on structure, control, and predictability. Hierarchy prioritizes order, formal procedures, and risk minimization. A system idea of efficiency, stability in bound rules. |
| Structure | Tiered and formalized. Authority flows vertically, reinforced by standardized policies, protocols, and compliance mechanisms. Decision rights are clearly delineated. |
| Engagement | Predictable but restrained. Employees appreciate role clarity and procedural stability, but are constrained in creativety, engagement thrives when they value consistency over autonomy. |
Leadership style | Leaders are administrators, coordinators. Focused on enforcing standards, ensuring quality, and maintaining operational continuity but Innovation is secondary. |
Innovation & Risk | Low and deliberate. Innovation is incremental, often procedural, and tightly scoped. Risk is minimized through rigorous planning, documentation, and oversight. |
| Best Fit | Suited for public institutions, healthcare systems, logistics networks, and regulated industries where compliance, safety, and procedural integrity are strategic imperatives.
Effective in environments with high accountability and low tolerance for error. |
Hierarchy is deeply rooted in internal anatomy and physiology, it’s the embodiment of functioning-as-control and safety-as-certainty.
It’s resilient but slow to adapt.
- Undefined Functionality: formalized through rules, protocols, and control systems.
- Strong functioning: predictable behavior, role clarity, and procedural adherence.
- Undefined safety: Risk is minimized through structure, redundancy, and compliance.
Innovation is constrained to protect stability.
❷
Market: the competitive arena
| Dimension | Description of the culture |
| Definition | Results oriented, external success metrics dominate. Thrives on competition, accountability, and relentless pursuit of performance. Winning isn’t just celebrated, it’s institutionalized. |
| Structure | Goal-centric and agile. While hierarchies may exist, roles flex to meet targets. Success is measured in deliverables, outcomes, and market impact, not effort or tenure. |
| Engagement | Polarized. High achievers flourish in the pressure-cooker; others disengage if intrinsic motivation or resilience is lacking. Hinges on alignment with ambition and rewards. |
Leadership style | Commanding and metric-driven. Leaders set clear expectations, enforce accountability, and reward performance. Decision-making is swift, data-informed, and often top-down. |
Innovation & Risk | Selective and ROI-bound. Innovation is pursued when it enhances competitive advantage. Risk is tolerated only when justified, experimentation is strategic, not cultural. |
| Best Fit | Ideal for sales-driven enterprises, financial services, high-growth startups, and consumer markets where speed, precision, and measurable outcomes are strategic imperatives.
Effective in environments with clear benchmarks and competitive dynamics. |
Market culture is a hybrid—leaning on external anatomy (delivery, supply) and neurological orchestration (metrics, incentives).
It’s efficient but brittle if safety isn’t embedded.
- Undefined functionality: tightly scoped to external success metrics.
- Balanced functioning: performance-driven, behavior is shaped by KPIs and incentives.
- Moderate safety: emotional or ethical safety may be secondary.
Risk is managed through ROI logic and compliance.
🚧 💰
There is no single “best” organizational culture. Only the one best suited to a strategic intent, environmental complexity, and stakeholder dynamics.
Each culture archetype embodies distinct strengths and trade-offs, and its effectiveness depends on how well it aligns with your system’s purpose, people, and pressures.
Incrementalism in policy and decision-making
Culture is not a prescription,it’s a strategic fit.
- ❸ Clan fosters loyalty, trust, emotional engagement. Ideal for service sectors, nonprofits & human-centric systems.
- ❹ Adhocracy unleashes innovation and agility. Perfect for volatile environments, startups and R&D domains.
- ❺ Hierarchy ensures stability, control & compliance. Critical in regulated sectors.
- ❷ Market drives performance, competition, and external results, where speed & metrics dominate.
The key is coherence: culture must resonate with your organizational DNA, stakeholder expectations, and transformation logic.
✅💰 This figure representing the four organisational types fits perfect to the SIAR compass.
A hybrid mix is the most logical for a network culture. Misalignment breeds friction; alignment enables flow.
A subsystem can have a different culture than its originator although there are influences and tensions for similarity.
🕳💣❌ The connection of "market" to a ViSM system-2 is logical correct and disturbing.
When a social system does collapse in this part, there will be a regression to a hierarchy or worse.
⟲ AK-2.6.3 Using roles/tasks vs using titles for a hierarchy
Incrementalism in policy and decision-making
We got mentioned a hierarchy but, what is becoming logical after that?
In political science, the term polyarchy (poly "many", arkhe "rule") was used by Robert Dahl to describe a form of government in which power is invested in multiple people.
It takes the form of neither a dictatorship nor a democracy. ... The closest to the democratic ideal any country has come is polyarchy.
This approach is not without disadvantages.
However, Lindblom soon began to see the shortcomings of polyarchy with regard to democratic governance. When certain groups of elites gain crucial advantages, become too successful and begin to collude with one another instead of compete, polyarchy can easily turn into: 💣 corporatism or oligarchy.
The market culture for an organisation, networking, as a democracy, seen as
best design basis of organizational structure (Dean Meyer 2025).
Market Economics Is the Most Powerful Mechanism of Social Coordination Known to Mankind.
The person who inspired me to study the application of market economics within organizations was renowned Yale professor emeritus of economics and political science, Dr. Charles "Ed" Lindblom.
I had the honor of meeting Ed at a small, invitation-only, conference in January, 1990.
He made it abundantly clear that market economics is the most powerful mechanism of social coordination known to mankind.
🎯
In fact, market principles work best in a well-planned organizational structure.
One key result: Agility. Like the global economy, a market organization can dynamically assemble teams of just the right specialists from anywhere in the enterprise, to address multiple parallel and ever-changing strategies (without having to restructure whenever strategies change).
🎯
Any given function (group of specialists) may be involved in multiple strategic initiatives and operational processes at any point in time.
Priorities are aligned, and everybody is focused on desired results.
This degree of agility cannot be accomplished by traditional bureaucratic processes, and certainly not by structures designed around today's strategies, matrixes, or fixed "engineered" processes.
Roles task for Projects, Programs, the Portfolio
Reviewing the C&C challenges in the perspective of delegations to the subsystem of organizing.
A wonderful blog about what PMO is about.
PMO office (Birdview: Ksenia Kartamysheva, july 2025). The promoted product is limited to internal PMO.
A Project Management Office (PMO) is a centralized group or department within an organization that defines and maintains project management standards and practices.
It provides oversight, governance, and support to ensure that projects are delivered effectively, efficiently, and in alignment with business objectives.
Depending on the organization’s size and maturity, a PMO can range from a small team supporting a few projects to a large strategic entity that oversees a company-wide portfolio.
There are different types of PMOs, each serving a distinct purpose:
- Project Management Office
Focuses on supporting individual projects.
Provides tools, templates, and administrative assistance, helping project teams follow consistent practices.
- Program Management Office
Oversees groups of related projects (programs).
Manages governance, aligns project efforts, and ensures the program delivers value as a whole.
- Portfolio Management Office
Takes a broader view, managing the full portfolio of projects and programs.
Aligns initiatives with strategic priorities and ensures resources are invested in the right areas.
Each type plays a different role, but all are designed to help organizations deliver projects more efficiently and strategically.
These are a fit for the: change, architecting, engineering, development layer controlling the four stages of those cycles (hierarchy over level 2-3 in adhocracy).
Enterprise PMO (EPMO)
An Enterprise Project Management Office (EPMO) operates at the highest strategic level within an organization.
Unlike traditional PMOs that focus on individual projects or departments, the EPMO is responsible for aligning all project, program, and portfolio activities with the organization’s overall business strategy and objectives.
The EPMO plays a central role in decision-making, governance, and performance measurement across the entire project landscape.
It acts as a bridge between executive leadership and project execution teams, ensuring that every initiative contributes to long-term goals and delivers measurable value.
Key characteristics of Enterprise PMO:
- Strategic Alignment: The EPMO ensures that project portfolios are prioritized based on their alignment with corporate goals, resource capacity, and expected return on investment (ROI).
- Enterprise-Wide Governance: Establishes consistent governance structures, reporting standards, and risk management practices across all departments and business units.
- Cross-Department Collaboration: Coordinates efforts across functions (e.g., IT, HR, Finance, Engineering) to eliminate silos and promote unified execution.
- Performance Monitoring: Tracks KPIs at the organizational level and provides insights to leadership through dashboards and executive reports.
- Change Enablement: Supports organizational change management initiatives and helps drive enterprise-wide transformation programs.
Typical functions of Enterprise PMO:
- Managing enterprise-level project portfolio selection and prioritization
- Enforcing governance standards across all PMOs or project teams
- Aligning resource allocation with strategic priorities
- Advising executives on investment trade-offs and capacity planning
- Driving process improvement and PM maturity across the organization
PMO approach type for complexity alignment and maturity
- Supportive PMO
serves as a resource hub, offering best practices, templates, training, and guidance–while allowing teams to manage projects independently.
It has minimal control, making it suitable for organizations with low project management maturity.
- Maintaining a project knowledge base
- Providing training and coaching
- Creating standardized templates and tools
- Controlling PMO
provides both support and governance by enforcing standard methodologies, tools, and documentation.
It offers moderate oversight and is ideal for organizations seeking consistency across projects.
- Standardizing processes and tools
- Requiring compliance with reporting and documentation standards
- Conducting audits and performance reviews
- Directive PMO
takes full control of project execution.
Project managers report directly to the PMO, which oversees budgets, schedules, and resources.
This model suits organizations running high-stakes, strategically critical projects.
- Assigning and managing project teams
- Controlling budgets and timelines
- Making key decisions on priorities and resource use
PMO approach type for complexity alignment and maturity
PMO roles
- PMO Director PMO strategic leader. Sets vision, aligns project portfolios with business goals and reports to the C-suite. Owns PMO performance, governance standards, and cross-departmental coordination.
- PMO Manager Oversees day-to-day PMO operations. Manages staff, ensures project governance is followed, and supports project managers in delivery and reporting. Bridges the gap between strategy and execution.
- PMO Analyst Focuses on data. Tracks KPIs, builds dashboards, analyzes project performance, and supports reporting to leadership. Helps identify trends, risks, and improvement opportunities.
- PMO Consultant An external or internal advisor who assesses PMO maturity, recommends improvements, and helps implement tools, frameworks, or transformations. Often brought in during scaling or change initiatives.
- PMO Administrator (or Coordinator) Handles administrative tasks like maintaining project documentation, updating schedules, booking meetings, and managing tools. Provides essential support to keep PMO operations smooth and organized.
Additional roles:
- Portfolio Manager Manages multiple projects or programs across business units. Prioritizes based on ROI, capacity, and strategic fit.
- Project Controller Focuses on financials: budgeting, forecasting, cost control, and ensuring financial accuracy at the project level.
- Resource Manager Allocates people across projects based on availability, skills, and workload. Works closely with PMs to avoid bottlenecks or underutilization.
- Tool/System Administrator Maintains and configures the PMO‘s software stack (e.g., PSA, PPM, reporting tools). Ensures integrations work smoothly and users are supported.
Alignment to an understandable structure is added to that.
The PMO roles presented ordered in the orientation of the SIAR grid structure and movements, gives associations on interactions.
In a figure:
See right side.
For the flow the continuous change by the duality change type in roles is what is keep moving.
Most of the team PMO roles are focussing for control in support of C&C.
Faciliators in the PMO (green areas) are the ones enabling the usablity.
Balancing the teams!
It's not just about getting the job done; it's about the process and the dynamics of how it's achieved.
How to use for a neurological and sociological fit by people is by Role-Task Fit Workshops:
- Short co-creation sessions where members self-assess their strengths, then map tasks/roles.
- Visual role-task boards showing who’s playing PMO manager, who Finacial controller, etc.
- Adjust assignments mid-cycle as instantiation needs evolve.
❗ The strange duality in stakeholder roles are added up in these PMO-roles for:
- The operational execution: <discipline>:StakeHolder<:M/E/V/C>:_xxx
- The policy decisions are: <discipline>:StakeHolder<:S/I/A/R>:_xxx
💡❓ Why can't the gap in C&C get solved in this way?
The culture mindset: Clan, Adhocracy, Market, hierarchy adds a dimension for stakeholders.
⟲ AK-2.6.4 Fractals in closed-loops, ViSM system-2, good regulator
BIDM and the closed loop, good regulator
The closed loop cycle, good regulator from knowing what is going on into strategic decisions vice versa, is the ultimate goal.
This document started with a simple review for analytics, using a central DWH but resulted in that conclusion.
"BIDM The_Business_Intelligence_Development_Model" (researchgate: C.Sacu M.Spruit 2010)
⏳
BI analytics is integrated or not in the business process can strongly affect the decision making process.
The used figure is already showing fractals, strategic. tactical, operational and a double closed loop for what is measured and what is a target at a moment.

It is the mindset of Bil Inmon that you should focus on the why of the information ata dashboard.
The why of a closed loop, good regulator, is needed and what it fulfils.
BIDM and systems that are fractals of systems
Realizing that systems are fractal of systems is a needed mindshift for simplifying the system.
What can be done at the edges, "power to the edges", should be solved as much as possible at the edges.
That implies the repeating structure of closes loops, good-regulators!
A representation of fractals:
| Understanding | Steer Direction Alignment | Shape Direction Setting plans | Serve Direction Execution |
Context, Concept | | | |
Logical, Physical | | | |
Components, instances | | | |
👁 every system in the system as a whole is using the closed loop, good-regulator for its interactions.
There is an overarching one for the system as a whole.
It is found in:
- The Belbin roles for operations, components - instances (the now - 3*3)
- The Belbin roles for tactics, logical - physical (near future - 3*3), see change-roles
- The Belbin roles for strategy, Context - Concept (far feature - 3*3), see PMO-roles
- Uncertainty for roles, stakeholders, influencing by the supersystem, social polycracy (6*6)
and found in others like the learning approach (student to mastery 3*3) in the scoped discipline.
💡❓ why can't the gap get solved in knowledge management of the whole (jabes)?
  
  
  
AK-3 Details systems ZARF practical 6x6 reference framework
AK-3.1 Enabling the practical undertstanding continuum
Understanding systems and changing systems are several levels of abstraction.
When changing systems the complexity on what should be done increases, it is about unpredictability non-linearity.
The biggest problem with that: the human demand of anything should be predictable and linear.
Challenges for change:
- Doing activities as always the same type of construction
- Improving the activities for achieving the same
- Improving type of construction although same purpose
- Creating new type of activities
- Creating new type of constructions
⟲ AK-3.1.1 Explanation model example: Adaptive Transit Planning
States in the external purpose line
RCA Search for cause (LI: Hanns-Jürgen Hodann 2025)
ROOT CAUSE ANALYSIS AND SYSTEMS THINKING ARE NOT COMPATIBLE
I have often seen Root Cause Analysis (RCA) being referred to in posts about systems thinking as if they were natural part of sit. However, they have completely different epistemic orientations.
TRADITIONAL ROOT CAUSE ANALYSIS (RCA)
The “5 Whys” or “Ishikawa/Fishbone diagrams” assume that Problems arise from a chain of events (A causes B, which causes C, etc.) and that by tracing this causal chain backwards, one can find a single or primary “root cause” whose removal will prevent recurrence. The logic is linear and reductionist and presumes that causality runs in one direction, and that problems can be fixed by targeting an identifiable, singular cause. ITS EPISTEMIC ENDEAVOUR IS KNOWLEDGE OF A SINGLE OR SMALL GROUP OF CAUSES WITH THE AIM TO REMOVE THEM.
SYSTEMS THINKING (ST)
ST does no seek to identify cause, which it regards as circular and distributed. Especially in the System Dynamics tradition, ST seeks a structural explanation for system behaviour based on feedback loops. ITS EPISTEMIC ENDEAVOUR IS THE STRUCTURAL EXPLANATION OF BEHAVIOUR WITH THE AIM OF IMPROVING IT.
Although some practitioners now argue that RCA can be used within a systems framework if one expands the notion of “root cause” to mean “root structure”, this assumption is flawed. In system dynamics terms, there is no singular root cause, because every element participates in multiple feedback loops.
systems thinking and modeling
What is the essence of systems thinking? I'm not looking for a definition.
We use ST to analyzes phenomena (to examine the nature of (something) by careful and close study) through their systemic relationships, feedback loops, delays, and structures to understand how patterns of behavior emerge over time.
Can we say it is a learning methodology?
Is a system also an absrtact term?" Yes, 'system' as a general description is also an abstract term, Gene. And as a verbal description or definition it cannot contain feedback loops, only physical instantiations and models can.
A solution to leader’s solitude dilemma (Olaf de Hemmer Gudme 23 juin 2025)
The 4 'systems' principles by Le Moigne compared to 'cartesian' principles:
| The ‘cartesian’ principles | Le Moigne ‘systems’ principles |
| Evidence: knowledge is absolute | Relevance: knowledge is relative |
| Analysis: understanding the whole by its parts | Globalism: understanding the object by its environment |
| Causality: causes / effects relations | Teleology: goals / means relations |
| Completeness: make sure you do not omit any detail | Agregativity: choose an overall representation |
We find here what is so much missing in many problem-solving issues:
- People’s point of views and subjectivity have to be taken into account
- The impact of things on the natural and human environment are major issues
- Goals, purpose, objectives, meaning … are crucial for people to design solutions
- Mapping a global view secures the 3 other principles
A goal is linked to people, so each relationship is established either directly between « stakeholders » or indirectly through relationships between physical elements that are themselves related to the stakeholders through other physical elements:
This is the basis of how Le Moigne proposes to model systems: by representing the relations of things with the elements in their environment, where flows crossing a thing from upstream to downstream are the ‘behavior / meaning’ exhibited by the system[6].
This tool gives system thinkers a way to improve modeling by not only showing ‘causal loops’ (a specificity of systems when mapped in a ‘cartesian’ way) but also showing people goals and needs, to take relevant design decisions.
Le Moigne’s principles shift stakeholder modeling from static enumeration to dynamic epistemic engagement:
- Stakeholders are not just “affected parties” but co-constructors of meaning and purpose.
- Their relevance is not fixed—it emerges through recursive dialogue and teleological alignment.
- A fractal stakeholder mapping logic where stakeholder roles are evaluated not just by impact but by their contribution to systemic coherence.
| Le Moigne | ZARF Layer Alignment | Interpretation |
| Relevance | Focus / Framing | Prioritizes meaningful distinctions and stakeholder salience—echoes ZARF's semantic integrity logic. |
| Globalism | Relational / Contextual | Emphasizes system–environment coupling, resonating with ZARF’s recursive boundary logic and external referents. |
| Teleology | Purpose / Intent | Directly maps to AK-2.1’s goal-orientation and readiness framing—especially in constructor–validator role logic. |
| Systemicity | Structure / Dynamics | Mirrors ZARF’s feedback loops, delays, and recursive flows. This could be embedded in readiness matrices and compass overlays. |
A sketch for the quadrant model integrating Le Moigne’s four system principles—Relevance, Globalism, Teleology, Systemicity—as semantic evaluators across stakeholder roles and flows.
This model will help visualize how stakeholder roles (Constructor, Validator, etc.) interact with systemic principles across abstraction layers and time slices.
These roles are not according the ones previous in the layers using unique names and belbin. Architect was proposed as constructor a tiele could be Chief engineer. Curator was Validator.
| Le Moigne | Dominant role | Flow focus | Interpretation |
| Q1 Relevance | Architect Implementer Validator PMO administrator | Engineering Identification | Ensures semantic integrity and stakeholder salience. Asks “Which distinctions matter?” |
| Q2 Globalism | Curator Monitor-Evaluator Constructor PMO analyst | Administration Conceptualization | Evaluates systemic coupling and external coherence Asks “Where are the boundaries?” |
| Q3 Teleology | Strategist Shapers Trickster PMO manager | Delivery Purpose | Aligns goals, motivations, and stakeholder intent Asks “Why does this system exist?” |
| Q4 Systemicity | Orchestrator Plants Inventor PMO consultant | Supply Realization | Manages recursive flows, feedback loops, and transformation logic Asks “How does the system behave over time?”. |
Scenario Adaptive Transit Planning
https://societalogy.com/
Scenario Adaptive Transit Planning
🔰 An explanation model serves in better understanding of abstract concepts. It should be well known for understanding, not too simmple and not too complex.
The choice is using the public transport system, transit of people and some chosen problem.
The chosen problem at Adaptive Transit Planning:
- A city’s transit authority detects a spike in commuter traffic during peak hours.
- The people using the public transport and those that impacted by impact of the spikes complain to the city's authorities.
- The transport system must adapt routes, schedules, and capacity in real time while maintaining safety, efficiency, and public trust.
🎭 This explanation model wille be used for the more complex and abstracted scenarios:
- Information FLow from Supply to Delivery (IFSD). Data contracts is a sub-topic in this.
- Platform Engineering (PE), This is what enables: Information FLow from Supply to Delivery.
- Information System Engineering (ISE). This is what set constraints for enables PE and IFSD
For these there is a translations mapping for the Semantics needed:
| ViSM | Semantic | Information FLow | Platform | Information System |
| system-1 | Context | | Platform Component | |
| system-3 | Concept | | Decision Node | |
| system-4 | System Logic | | Stakeholder Role | |
| system-5 | Technology | | Resource | |
| system-2 | Components | | Feedback Loop | |
| system-1 | Instance | | Governance Rule | |
Intelligence for Adaptive Transit Planning
🚧 The proposed intelligence result:
| eDIKWv | Abstract | Action / activity |
| Environment | Instance | Sensors collect passenger counts, GPS positions, and ticket scans |
| Data | Components | Data is structured into heatmaps, route congestion graphs |
| Information | Technology | Analysts identify patterns: peak congestion zones, bottlenecks |
| Knowledge | System Logic | Predictive models suggest rerouting and dynamic scheduling |
| Wisdom | Concept | Strategic decision: deploy extra buses, notify public, adjust pricing |
| Vision | Context | Routes updated, drivers dispatched, public alerts sent |
🚧 Feedback & Recursion:
- Feedback Loop: Passenger satisfaction surveys and real-time telemetry feed back into the Insight layer.
- Entropy Check: If signal clarity drops (e.g., conflicting data), rollback to Knowledge layer and reprocess.
- Trust Calibration: Public trust scores influence Wisdom decisions—if trust is low, more transparency is injected.
🚧 Time-Sliced Contexts:
- Now: Real-time telemetry, congestion alerts, incident response
- Near Future: Predictive modeling, schedule adjustments, stakeholder communication
- Far Future: Strategic planning, infrastructure investment, policy evolution
Roles and flows for Adaptive Transit Planning
⚠ Although this would be a simple model example there are surprises. When these contents was created the compononts abstractions got missing.
Raising the question for undertanding why it was missing with a hint for what it could be, the problem for a role became clear, an alternative being created: Transit Orchestrator.
For roles in the components there is an ambiguity:
- Dispatch Coordinator: Assigns buses and drivers based on system logic and real-time conditions
- Fleet Scheduler: Adjusts vehicle deployment based on predictive models and operational feedback
- Commuter Planner Designs service offerings and adapts them to demand patterns and constraints
- Driver Interface Manager Ensures drivers receive accurate, timely instructions via onboard systems
🚧 Engineering - constraints for the how, role mapping across layers:
| Role | Abstract | Action / activity |
Strategic Planner Operations Coordinator | Context | Defines long-term mobility goals, equity, and sustainability vision |
| Governance Lead | Concept | Aligns stakeholder mandates, policy frameworks, and legitimacy logic |
| Insight Strategist | System Logic | Synthesizes predictive models, scenario planning, and decision paths |
| Data Analyst | Technology | Builds routing algorithms, congestion forecasts, and telemetry logic |
| Transit Orchestrator | Components | Configures dispatch tools, assigns vehicles, calibrates driver interfaces |
| Bus Driver / Sensor Network | Instance | Executes routes, collects real-time data, and responds to conditions |
🚧 How the components in the system are expected to work as a whole:
| Flow | Contextual Lens | Transit Planning role |
| Engineering | SDLC, route optimization, sensor logic | Designing adaptive schedules and routing algorithms |
| Administration | Governance, public trust, cultural fit | Ensuring legitimacy, fairness, and stakeholder alignment |
| Delivery | Service execution, customer experience | Managing real-time operations and passenger flows |
| Supply | Resource allocation, vendor coordination | Aligning buses, drivers, and infrastructure |
Fractals for details getting to work instructions in Adaptive Transit Planning
⌛ ⏳What is next, Visual Implications.
(LLM:)
This dashboard can be rendered as a vertical swimlane diagram:
- Each ZARF layer as a horizontal band
- Roles mapped to their respective layers
- Arrows showing decision flow (top-down) and feedback (bottom-up)
- Exception channels and compensation paths highlighted in red
Would you like to simulate a breakdown scenario—say, when the Insight Strategist misreads demand—and trace how the system recovers through ZARF_VIRU_04? We could model that next.
Adaptive Transit Planning 6*6 Matrix: Semantic Mapping
Questions that help structure stakeholder understanding across context layers & abstraction layers.
❶ Alignment by What en How:
| What (define) | How (Categorize) |
| Context | What is the scope in mobility equity, urban sustainability? | How is the Strategic transport policy defined for mobility? |
| Concept | What are the intended service coverages, accessibility goals? | How is Adaptive routing strategy structured? |
| System Logic | What are the congestion thresholds, rerouting logic? | How are Optimization heuristics, feedback loops strcutured? |
| Technology | What is there possible in Routing algorithms, telemetry dashboards? | How is a Scheduling engine, load balancing, shaped - measured? |
| Components | What information is usefull by Ticket scanners, sensors? | How are Vehicle specs, driver protocols giving constraints? |
| Instance | What information to collect in Passenger counts, GPS logs? | How are Bus movements, stop timing impacting dynamics? |
❷ Alignment by Where en Who:
| Where (Classify) | Who (Name) |
| Context | Where are the issues: Urban geography, population density? | Who Governance structure, public mandates? |
| Concept | Where does the Service area definitions apply? | Who have what Stakeholder roles (citizen, operator)? |
| System Logic | Where does Zone prioritization, route clustering have impact? | Who has what role in an Accountability matrix, escalation logic? |
| Technology | Where is GIS mapping, zone definitions to be found? | Who has what access (Role-based), and act in escalation paths? |
| Components | Where is an Infrastructure layout to be found? | Who defines Role assignments, shift plans? |
| Instance | WHere are transport stops (Bus Metro Train), stations located? | Who assings Drivers, dispatchers? |
❸ Alignment by When en Which:
| When (Time) | Which (Distinguish) |
| Context | When: by Strategic timeframes (Now, Near, Far Future)? | Which strategic option to select, legitimacy validated? |
| Concept | When: by the Planning horizons (daily, weekly)? | Which Scenario to be chosen, trade-off resolved? |
| System Logic | When: in Time-slice orchestration, exception triggers? | Which influences are dominant or latent? |
| Technology | When: for Real-time updates, predictive alerts? | Which Algorithm to be chosen, threshold applied? |
| Components | When: for Timetables, shift calendars? | Which Vehicle to be assigned, resources to get allocated? |
| Instance | When: in Peak hours, delays? | Which Route to be selected, actions to be taken? |
⟲ AK-3.1.2 Practice Example: Information FLow from Supply to Delivery
Scenario Information FLow from Supply to Delivery
⟲ AK-3.1.3 Practice Example: Platform Engineering
Scenario Platform Engineering
The discipline of Platform Engineering in the Information Technology context, is primarily situated in the Technology domain, but it interacts deeply with People (stakeholders, users, operators) and Processes (budgeting, lifecycle, compliance).
Platform Engineering 6*6 Matrix: Semantic Mapping
Questions that help structure stakeholder understanding across context layers & abstraction layers.
❶ Alignment by What en How:
| What (define) | How (Categorize) |
Platform Component | What are the components (e.g., CI/CD, observability, identity)? | How is it grouped (infra, app, data, security)? |
Decision Node | What is the decision (e.g., upgrade, deprecate, patch)? | How is it structured (manual, automated, policy-driven)? |
Stakeholder Role | What is the role (e.g., platform engineer, SRE, architect)? | How is it categorized (builder, operator, enabler)? |
| Resource | What is the resource (e.g., compute, storage, licenses)? | How is it classified (shared, dedicated, ephemeral)? |
Feedback Loop | What feedback is generated (metrics, logs, alerts)? | How is it structured (push/pull, closed/open)? |
Governance Rule | What policy applies (e.g., access, compliance)? | How is it enforced (RBAC, audit, automation)? |
❷ Alignment by Where en Who:
| Where (Classify) | Who (Name) |
Platform Component | Where is it deployed (cloud, edge, hybrid)? | Who owns or maintains it? |
Decision Node | Where does it apply (domain, environment)? | Who decides or approves? |
Stakeholder Role | Where does it act (infra, app, governance)? | Who embodies the role (persona, team)? |
| Resource | Where is it allocated (cluster, tenant)? | Who consumes or provisions it? |
Feedback Loop | Where is it routed (dashboard, alerting system)? | Who receives or acts on it? |
Governance Rule | Where is it scoped (global, local, tenant)? | Who governs or escalates? |
❸ Alignment by When en Which:
| When (Time) | Which (Distinguish) |
Platform Component | When is it provisioned, scaled, retired? | Which components are critical, optional, redundant? |
Decision Node | When is it triggered (event, schedule)? | Which options are viable, risky, deferred? |
Stakeholder Role | When is the role active (lifecycle stage)? | Which roles overlap or conflict? |
| Resource | When is it needed or constrained? | Which resources are bottlenecks or elastic? |
Feedback Loop | When is it reviewed or escalated? | Which feedback loops are convergent or noisy? |
Governance Rule | When is it evaluated or refreshed? | Which rules are flexible, strict, obsolete? |
Fractals for details getting to work instructions in Platform engineering
🚧 ZARF Integration:
- Anatomy Axis: Use vertical layers (Context → Instance) to show how platform components evolve from abstract capability to concrete deployment.
- Physiology Axis: Use horizontal flows (Engineering, Administration, Delivery, Supply) to show how platform decisions propagate across domains.
- Time Slices: Apply Now / Near Future / Far Future overlays to model lifecycle, roadmap, and transformation logic.
- Recursive “Which”: Drill into trade-offs, prioritization, and scenario modeling for platform evolution.
⌛ ⏳What is next, Visual Implications.
(LLM:)
Resulting Artifacts:
- A Platform Engineering Compass for decision modeling
- A Role-Task Matrix for stakeholder alignment
- A Feedback-Governance Overlay for closed-loop control
- A Resource Allocation Map for bottleneck detection
- A Scenario Planner for roadmap and budget alignment
Would you like to co-design one of these artifacts—say, the Platform Engineering Compass or the Role-Task Matrix—using your ZARF overlays and AK-1.4 feedback logic?
⟲ AK-3.1.3 Practice Example: Information System Engineering
Scenario Information System Engineering
The problem:
AK-3.2 The Purpose of defending against external threats
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
⟲ AK-3.2.1 Context: Safety a functional requirement topic
The displaced position at technlogy
⟲ AK-3.2.2 Safety in orderd external states axis
Roles, Tasks, Methodologies for a safe environment for the system as whole.
- Where 👁 Demarcation
- Define trust zones via network segmentation (VLANs, subnets, micro-segments) to isolate workloads and data.
- Map data classification (public, internal, sensitive, restricted) and enforce controls at each zone boundary.
- Gate all ingress/egress through identity-aware proxies or API gateways to make boundaries explicit.
- How 👁 Deny
- Apply principle of least privilege with RBAC/ABAC so entities see only what they absolutely need.
- Configure firewalls, network ACLs, and Zero-Trust Network Access (ZTNA) to block everything except whitelisted traffic.
- Use strong authentication (MFA, certificates, hardware tokens) before granting any access.
- What 👁 Delay
- Implement rate-limiting on login and sensitive APIs to thwart brute-force and automated scans.
- Plant canary tokens, dummy credentials, or hidden honey-files in critical systems; their use triggers alerts and stalls attackers.
- Design chokepoint proxies or jump-hosts that force lateral traffic through monitored sprint-break checkpoints.
- Which 👁 Deter
- Display legal banners, warning notices, and visible security posture cues (e.g., login quarantine pages, phishing-resistant UX).
- Run continuous security training and phishing drills to make every user a tripwire for social engineering.
- Publicize red-team findings, bug-bounty programs, or incident post-mortems to signal active defense.
- When 👁 Detect
- Centralize logs with a SIEM or XDR platform that correlates network, endpoint, and cloud telemetry in real time.
- Deploy EDR agents, network IDS/IPS, and anomaly-based monitoring to flag behavior deviations.
- Use honeypots, deception networks, or attack-surface scanners to capture reconnaissance and lateral-movement attempts.
- Who 👁 Defend
- Maintain tested incident response plans, run tabletop exercises, and integrate IR into your CI/CD pipelines.
- Harden systems through patch management, secure configurations (benchmarks), and regular vulnerability assessments.
- Ensure immutable backups, disaster recovery rehearsals, and business-continuity workflows are always up to date.
⟲ AK-3.2.3 Safety external goals in transfomations
transfromation reasoning
- Demarcation ➡ Deny By establishing clear boundaries, you know exactly where to enforce access controls and stop unauthorized connections.
- Deny ➡ Delay When a denial fails or is bypassed, slowing down an attacker gives your team more time to react and catch anomalies.
- Delay ➡ Deter As adversaries hit friction, overt deterrents reinforce that the environment is hostile and not worth their effort.
- Deter ➡ Detect Even when deterrence fails, an environment primed for visibility helps you spot intruders faster.
- Detect ➡ Defend With timely detection, your incident response playbooks can activate, containing threats before they escalate.
⟲ AK-3.2.4 Safety negative results by assumptions
transfromation threats
Common Mistakes to Avoid in Transitions Between the Six D's
- Demarcation ➡ Deny Avoid assuming that simply drawing boundaries automatically enforces blocks.
Common errors include:
- Overlooking invisible data flows that bypass segmented networks
- Relying on perimeter firewalls alone without enforcing host-level access controls
- Failing to align demarcation zones with actual user and application trust boundaries
- Deny ➡ Delay Don't treat denial as the only barrier before introducing friction. Pitfalls often seen:
- Implementing blanket blocks without graduated throttling for borderline cases
- Neglecting to instrument rate-limits and canary tokens until after access controls are in place
- Forgetting to calibrate delays so they don't degrade legitimate user experience
- Delay ➡ Deter Resisting the urge to layer visible warnings once friction is in place can undermine deterrence. Watch out for:
- Skipping user-facing notices and legal banners after implementing slowing tactics
- Relying on hidden delays (e.g., silent throttling) without any overt signal to attackers
- Treating deterrence as a one-off rather than reinforcing it continuously through training and signage
- Deter ➡ Detect Failing to bake in detection after raising visible barriers leaves you blind to stealthy probes. Avoid:
- Assuming that warnings alone will halt reconnaissance or automated scans
- Overlooking monitoring of decoy assets (honeypots) once overt deterrents are visible
- Neglecting to correlate deterrence events (e.g., banner clicks) with log and alert streams
- Detect ➡ Defend Catching intruders without clear response steps turns alerts into noise. Common missteps include:
- Generating high-volume alerts without pre-defined playbooks for containment and recovery
- Not integrating detection tools into incident-response workflows and ticketing systems
- Delaying patching and hardening after an alert instead of triggering automated defense actions
By steering clear of these transition pitfalls, you ensure each flows smoothly into the next, building a coherent, layered cybersecurity posture that not only blocks threats but actively slows, warns, spots, and counters them.
Imagine a public digital service platform suffers a major outage during a benefits disbursement cycle. Citizens are frustrated, media scrutiny intensifies, and political pressure mounts. The system must respond not just technically—but socially.
Rule ID Activated Role During Crisis
XPOS_01 Reasserts system identity and clarifies its social role
XPOS_02 Aligns crisis response with cultural expectations
XPOS_03 Adapts behavior to ecosystem feedback and stakeholder needs
XPOS_04 Manages reputation, restores legitimacy, and rebuilds trust
Example: Public Trust Recovery Timeline
Phase Action
Day 1 Acknowledge outage, publish initial facts, activate crisis team
Day 2–3 Share recovery plan, open feedback channels, engage media
Week 1 Publish postmortem, announce policy adaptations, begin trust rebuild
Month 1 Launch citizen listening sessions, update governance protocols
Quarter 1 Release audit findings, track reputation metrics, reinforce legitimacy
ZARF_XPOS during crisis acts like a public-facing immune system:
XPOS_01 is the face—reassuring identity
XPOS_02 is the voice—speaking with empathy
XPOS_03 is the reflex—adapting to feedback
XPOS_04 is the memory—learning and rebuilding trust
AK-3.3 Value streams by systems the subsystems in a universe
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
⟲ AK-3.3.1 About Frameworks for architecture
What are Frameworks?
Examples for the goals in transformations
Combining:
7 abilities of execution with
7M process management (Alper Ozel 2025
Positive actions in transformations
- Universe ➡ (Where) Application Portfolio Detect Abnormalities:
A skilled person can identify problems in early stages before they cause significant damage or downtime.
This requires constant vigilance and attention to detail during regular operations, developing sensitivity to indicators that may suggest potential issues.
Sensitivity to: subtle changes in performance, unusual sounds, vibrations.
- (Where) Application Portfolio ➡ (How) capability maps Regulate to normal:
Once abnormalities are detected, executives / operators must be able to restore equipment to normal operating conditions.
This requires executives / operators to develop technical skills and judgment to determine which issues they can address by themselves and which require special assistance.
This ability necessitates basic understanding of equipment principles.
Tasks like tightening loose connections, replacing worn parts, lubrication or basic adjustments are in this category
- (How) capability maps ➡ (What) master data management Analyze Factors:
Executives / Operators must develop analytical skills to trace issues to root causes rather than simply addressing symptoms.
If operators understand the relationship between various components and systems, this allows them to connect seemingly unrelated symptoms to common causes.
By understanding the principles of how equipment functions, operators can make informed decisions
- (What) master data management ➡ (which) holistic overview Understand Causes:
Understanding deeper knowledge of equipment functionality and working principles, allows operators to troubleshoot effectively and implement preventive measures.
Thus, they can identify not just what went wrong but why it went wrong and how to prevent it in future
- (Which) holistic overview ➡ (When) track your master flows Establish Conditions:
Executives / Operators must learn to set clear standards that define normal operating conditions.
This includes developing specific schedules for cleaning, lubrication and inspection; component wear limits, and performance metrics.
By establishing conditions, operators create objective standards that remove ambiguity from decisions and ensure consistency across
- (When) track your master flows ➡ (Who) Track your ideas Improve Conditions:
Executives / operators must develop the ability to improve difficult to perform tasks.
This ability allows executives / operators to reduce routine tasks, conducted at longer intervals, and completed in less time.
This is a shift from reactive to proactive thinking, where executives operators actively seek ways to improve performance and reliability through design modifications, procedure updates
- (Who) Track your ideas ➡ Universe Manage Conditions:
As top ability, executives / operators must comply with rules and procedures while also establishing new rules to ensure compliance.
This management ability transforms executives / operators into equipment stewards who not only follow protocols but also contribute to development/enforcement.
AK-3.4 Choices by systems as capabilities by uncertainties
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
⟲ AK-3.4.1 About Frameworks for architecture
Technology components enablers in strategy missions
5 ways to link strategy to operations (Andrew Constable 2025)
(and not let your execution fall apart).
Most organisations plan big. But the execution? That’s where things break down.
Here are 5 strategic-operational linkage points that keep your vision connected to results:
- Fund and track your strategic initiatives
- Strategy without funding = fantasy.
- Strategy without tracking = chaos.
Prioritise based on ROI, feasibility, and strategic fit.
Track progress through dashboards and reviews.
ROI stands for Return on Investment.
It’s used as a key criterion for prioritizing strategic initiatives. The author suggests that organizations should fund and track initiatives based on:
- ROI: What measurable value will this initiative deliver?
- Feasibility: Can it be realistically executed?
- Strategic Fit: Does it align with long-term goals?
In essence, ROI here is not just financial—it’s a signal of strategic relevance and impact.
- Tie strategy to ops and finance
- Initiatives must create visible operational and financial outcomes.
- If it doesn’t become part of BAU, it was just a project, not a strategy.
Think cost savings, process improvements, revenue gains.
for strategy to have lasting impact, it must be embedded into the organization’s ongoing operations and routines (BAU) for strategy to have lasting impact, it must be embedded into the organization’s ongoing operations and routines (BAU Business As Usual).
That’s the litmus test for whether it’s transformational or just temporary.. That’s the litmus test for whether it’s transformational or just temporary.
- Let strategic targets drive long-term planning
- Your goals should shape your financial roadmap.
- customer growth or sustainability part of your financial roadmap.
Targets should guide budgets and investments.
Misalignment here = wasted time and missed impact.
- Build your driver models
- Every strategy needs a “cause and effect” system.
- Use value trees or SIPOC diagrams to map what drives outcomes.
Decision-making improves when you can connect actions to results.
SIPOC stands for:
- Suppliers: Who provides the inputs?
- Inputs: What resources are needed?
- Process: What steps are taken?
- Outputs: What results are produced?
- Customers: Who receives the outputs?
In this context, SIPOC diagrams are recommended to map cause-and-effect relationships between strategy and execution.
- Review. Analyze. Adjust.
- Strategy is not a one-time plan.
- Validate assumptions.
Set regular (monthly/quarterly) review cycles.
Take action. Iterate fast.
What makes these 5 links so strong?
You create a system of execution, learning, and strategic agility.
This is how alignment works.
In a figure:
see right side.
Two cycles strategy and operations are connected by defining systems.
Flow in of Strategic Thinking
strategic-thinking (Andre Constable 2025)
Strategic thinking is the cornerstone of effective leadership, sound decision-making, and long-term organisational success.
It goes beyond the confines of traditional planning, enabling leaders to make integrated, courageous choices in the face of uncertainty.
In today's complex and fast-changing world, the ability to think strategically has become essential for survival and sustained performance.
- Future Orientation Strategic thinkers do not merely solve today's problems, they look ahead.
They explore emerging trends, anticipate disruptions, and use structured tools such as scenario planning, PESTLE analysis, and competitive landscape assessments to guide long-term decisions.
- Systems ThinkingOrganisations are part of broader ecosystems.
Strategic thinkers recognise interdependencies across functions, partners, industries, and geographies.
This holistic view is crucial for addressing systemic challenges and capitalising on cross-sector opportunities.
- Hypothesis-Driven Strategy Effective strategies are built on assumptions.
Strategic thinkers make these assumptions explicit and test them rigorously.
Whether through war-gaming, pilot projects, or feedback loops, they continuously refine their approach based on evidence.
- Clarity and FocusClarity in purpose, values, and direction is a hallmark of strategic thinking.
These elements act as guardrails, shaping what the organisation will and will not do. Organisations that define their identity clearly are more likely to make coherent, disciplined choices.
Core Dimensions of Strategic Thinking
Strategic thinking must be embedded at every level of the organisation, not confined to the C-suite. This requires structured yet flexible processes that promote:
- What ➡Strategic Development Organisations must start with a clear mission and vision, conduct robust internal and external analysis, and define strategic shifts that reflect changing realities.
- How ➡Strategic Translation High-level thinking must be translated into actionable strategies.
Tools such as strategy maps and Balanced Scorecards help articulate cause-and-effect relationships and align teams around common goals.
- Where ➡Organisational Alignment Strategic coherence across business units is essential.
Each team must understand its role in the broader strategy and be empowered to adapt that strategy to its specific context.
- Who ➡Operational Planning Daily operations should reflect strategic priorities.
Leaders must ensure that budgets, initiatives, and KPIs are aligned with long-term objectives, not just short-term performance targets.
- When ➡Monitoring and Learning Strategy should be treated as a living process. Organisations must build feedback loops, review performance data, and be prepared to adjust their approach based on new information or shifts in the environment.
- Which ➡Strategic Agility In an era of rapid change, agility is key. Strategic thinking equips organisations to anticipate multiple futures and adjust course when necessary. Practices like contingency planning and strategic foresight enable resilience.
The why of Strategic Thinking
Strategic Thinking vs. Strategic Planning
While the two concepts are often used interchangeably, they are fundamentally different.
- Strategic planning focuses on implementation, developing roadmaps, timelines, and action plans.
- Strategic thinking focuses on insight, challenging assumptions, identifying leverage points, and choosing where and how to compete.
Planning tends to be linear and predictable.
Strategic thinking embraces complexity and uncertainty.
One is about execution; the other is about advantage.
"Having a good strategy with no execution is a big disappointment.
But having no strategic thinking at all is a failure in leadership."
Roles, Tasks, Methodologies for a safe working environment in the system.
Example Scenario
Let’s say How–Component is being updated to reflect a new automation tool:
Governance rules from How–Concept require ISO 27001 compliance
The new tool lacks encryption, violating the inherited constraint
ZARF blocks the transformation, logs the violation, and alerts the compliance officer
A feedback loop is triggered to review whether the policy needs adaptation or the tool must be replaced
Transformation: How–Component
┌─────────────────────────────┐
│ Inherited Constraints: │
│ • ISO 27001 compliance │
│ • Role-based access control │
│ │
│ Audit Log: │
│ • Actor: DevOps Lead │
│ • Timestamp: 2025-09-16 │
│ • Status: Blocked │
│ • Reason: Encryption missing│
│ │
│ Feedback Triggered: │
│ • Policy review initiated │
└─────────────────────────────┘
Example Scenario
Let’s say a new product launch affects:
What–Concept (strategic intent)
How–Technology (platform selection)
Who–Instance (staffing and roles)
When–Component (deployment schedule)
ZARF decomposes this into atomic moves:
Each move is sequenced and assigned to a team
A System-2 cell coordinates across flows
All moves occur in the “Near Future” slice
A rollback path is defined in case How–Technology fails compliance
🧩 Visual Cue (Conceptual)
Code
Composite Transformation: Product Launch
┌─────────────────────────────┐
│ Sequence: │
│ 1. What–Concept │
│ 2. How–Technology │
│ 3. Who–Instance │
│ 4. When–Component │
│ │
│ Coordination: │
│ • System-2 Cell: PL-Coordinator │
│ • Time Slice: Near Future │
│ • Handoff: to Delivery team │
│ │
│ Audit Log: │
│ • Actor: Strategy Lead │
│ • Status: In Progress │
└─────────────────────────────┘
Example Scenario
Let’s say Which–Component is being updated to reflect a new supplier module:
The module fails compliance checks during How–Technology validation
Exception channel triggers rollback of Which–Component to previous version
Compensation path updates Who–Instance to revert staffing assignments
All changes are logged, and a feedback loop is triggered to review supplier criteria
🧩 Visual Cue (Conceptual)
Code
Transformation: Which–Component
┌─────────────────────────────┐
│ Exception Trigger: │
│ • Compliance failure │
│ │
│ Compensation Path: │
│ • Rollback to prior version │
│ • Notify Who–Instance │
│ │
│ Time Slice: Near Future │
│ │
│ Audit Log: │
│ • Actor: Procurement Lead │
│ • Status: Reverted │
└─────────────────────────────┘
AK-3.5 Resource continuity of the system in a universe
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
⟲ AK-3.5.1 Aligning Culture theory and culture observations
Out of the box orgnisation evolution
Applying Stafford Beer's Viable System Model (ViSM) to the evolution of social and organizational structures.
In the order of engineering, flexibility and discretion - administration stability and control:
| VSM System | Social Structure | Meta | Role |
| System-1 | Individual | What | Basic operational unit, self-regulating |
| System-3 | Clan | How | Internal regulation, shared norms, resource control |
| System-4 | Adhocracy | Where | Innovation, adaptability, exploration |
| System-5 | Hierarchy | Who | Policy, identity, long-term stability |
| System-2 | Market | When | Coordination through exchange, price signals |
| universe | Polycracy | Which | -the supersystem and inheritance- |
The attention for focus is at: Adhocracy vs Hierarchy.
The problem for that is getting a well defined good regulator.
Markets coordinate but don’t inherently regulate for fairness, sustainability, or long-term viability.
They need meta-regulation or embedded ethics to function as part of a viable system.
A polycracy implies multiple centers of governance or decision-making—distributed authority.
How each system maps onto organizational structures today:
- System 1 – Individual (Operational Units)
- Employees, teams, departments doing the core work.
- Each unit should be semi-autonomous, capable of self-regulation and decision-making within its scope.
- Modern parallel: Agile teams, cross-functional pods, remote workers.
- System 3 – Clan (Control & Regulation)
- Internal governance via culture, shared values, informal norms.
- This is often overlooked but crucial—think of company culture, peer accountability, and community-driven standards.
- Modern parallel: DAOs (Decentralized Autonomous Organizations), holacracy, or community-led startups.
- System 4 – Adhocracy (Innovation & Intelligence)
- Strategic foresight, R&D, innovation labs, and adaptive planning.
- This is where organizations explore new markets, technologies, and ideas.
- Modern parallel: Skunkworks, innovation hubs, design thinking teams.
- System 5 – Hierarchy (Policy & Identity)
- The executive layer, board of directors, or founding vision.
- Sets the mission, values, and long-term direction.
- In polycratic models, this might be distributed governance or consensus-based leadership.
- System 2 – Market (Coordination)
- Coordination between units through contracts, KPIs, or market-like mechanisms.
- In decentralized organizations, this could be internal marketplaces or token-based economies.
- Challenge: ensuring ethical and sustainable coordination, not just efficiency.
- Universe – Viable polycracy:
- Each subsystem (individual, clan, market, adhocracy, hierarchy) retains autonomy but is interlinked.
- Regulation emerges from feedback loops, shared values, and adaptive intelligence.
- It’s non-monolithic, yet coherent—like a living organism.
Implications
- Resilience: Multiple systems can compensate for each other.
- Adaptability: Adhocracy and market dynamics allow rapid response.
- Stability: Clan and hierarchy provide grounding and continuity.
- Ethical Coordination: The challenge is embedding values into System 2 (market) and System 4 (adhocracy).
In the order of internal integration - external differentation:
| VSM System | Social Structure | Meta | Role |
| System-4 | Adhocracy | Where | Innovation, adaptability, exploration |
| System-3 | Clan | How | Internal regulation, shared norms, resource control |
| System-1 | Individual | What | Basic operational unit, self-regulating |
| universe | Polycracy | Which | -the supersystem and inheritance- |
| System-2 | Market | When | Coordination through exchange, price signals |
| System-5 | Hierarchy | Who | Policy, identity, long-term stability |
The attention for focus is at: Individual vs Polycracy.
Polycracy case study wiht VISM & Zarf
Morning Star is a California-based tomato processing company renowned for its entirely self-managed, peer-driven organizational model—a prime example of integrating individual autonomy, clan culture, market-like coordination, adhocratic innovation, and minimal hierarchy to achieve viability.
-
System 1 – Individual (Operational Units)
- All employees are self-managing, with no formal supervisors.
- Each person defines their own roles via Colleague Letters of Understanding (CLOUs), detailing responsibilities and mutual expectations.
- System 3 – Clan (Control & Regulation)
- A strong peer culture upholds values of trust and voluntary commitments.
- Conflicts are resolved through direct negotiation, peer mediation, or small panels—without relying on hierarchical control.
- System 4 – Adhocracy (Innovation & Intelligence)
- The organization continuously adapts and improves, guided by evolving peer agreements.
- There’s informal innovation through cross-functional collaboration and emergent improvement from within the system—no separate R&D hierarchy.
- System 5 – Hierarchy (Policy & Identity)
- While legally structured as a corporation, operationally it's flat.
- The sole owner sets high-level purpose and maintains accountability (policy function), but delegates daily authority to the collective.
- System 2 – Market (Coordination)
- Coordination occurs through negotiated agreements.
- Employees contract with colleagues—like a mini-market—to define task interactions and deliverables, supported by peer accountability.
- Why This Is a Viable Polycracy
- Distributed authority: decision powers rest with individuals and peers.
- Feedback loops & coordination: CLOUs and peer negotiations create dynamic interdependence.
- Value-embedded control: trust and voluntary norms regulate behavior, not top-down orders.
- Adaptive intelligence: continuous internal evolution without rigid hierarchies.
- Minimal hierarchy: a policy-level anchor points to company identity and long-term continuity
Key Takeaways for Modern Organizations
- Self-management is feasible at significant scale (~600 permanent + 4,000 seasonal workers).
- Market-like coordination (negotiated agreements) can effectively substitute for traditional management.
- Clan-based culture and peer accountability enable high trust and lower bureaucracy.
- Innovation emerges organically through system design rather than dedicated departments.
By viewing Morning Star through the lens of VSM Zarf, you see a living exemplar of how a viable polycracy functions in the real world—balancing autonomy, coordination, adaptability, and identity without heavy hierarchies.
To predict how Morning Star might evolve as it scales further—while maintaining its viable polycratic structure—we can explore how each VSM system might adapt:
- Individual (Operational Units)
- Current: Self-managed individuals with CLOUs.
- Future: May evolve into micro-enterprises or internal cooperatives, each with their own mini-VSM structure.
- Challenge: Maintaining autonomy while ensuring alignment across a growing workforce.
- Clan (Control & Regulation)
- Current: Strong culture and peer accountability.
- Future: Might formalize peer review systems, reputation scores, or community councils.
- Challenge: Preserving organic culture while introducing scalable governance.
- Adhocracy (Innovation & Intelligence)
- Current: Informal innovation through collaboration.
- Future: Could develop distributed innovation networks, open R&D platforms, or cross-company alliances.
- Challenge: Balancing exploration with operational focus.
- Hierarchy (Policy & Identity)
- Current: Minimal hierarchy, founder-led vision.
- Future: Might evolve into a distributed leadership model, possibly with rotating stewards or values-based councils.
- Challenge: Maintaining coherence of identity across a decentralized structure.
- Market (Coordination)
- Current: Peer-to-peer agreements.
- Future: Could adopt smart contracts, internal tokens, or AI-assisted negotiation platforms to scale coordination.
- Challenge: Avoiding transactional overload or loss of human trust.
- Emergence of a Meta-System: Polycratic Governance. As Morning Star grows, it may need a meta-system to:
- Integrate feedback across all systems.
- Ensure ethical coherence and strategic alignment.
- Enable adaptive governance without reverting to rigid hierarchy.
This could take the form of:
- A digital nervous system (AI + data feedback loops).
- A governance protocol (like in DAOs).
- A values-based constitution guiding all decisions.
Why organisations miss the real story
Sellin a tool,
Listening beyond the metrics: (cynefin company 2025)
Many organisations believe they’re listening to their people, customers, or partners, but in reality, they’re often only collecting surface-level noise.
Here’s what we’ve learnt time and again when working with leaders navigating complexity:
- Understanding how they currently listen:
Most organisations rely on cheap surveys, pulse checks, and dashboards. These tools offer neat graphs, but often mask the messy, emotional, human realities underneath.
Listening shouldn’t stop at numbers; it should start with stories.
- Pain points wiht chep feedback & insight:
Surveys flatten meaning. They box experience into pre-defined options, leaving no space for nuance, contradictions, or weak signals. When we reduce people to tick-boxes, we lose the why behind the data.
- Decision making under complexity:
When the landscape is shifting fast, yesterday’s metrics won’t help you see tomorrow’s challenges. What leaders truly need is early warning signals, insights that come from lived experience, not just reporting cycles.
- Appetite for narrative insight:
More and more organisations are recognising that quantitative dashboards alone don’t build trust or foresight. They’re turning towards approaches that embrace hashtag#narrative, uncertainty, and diverse perspectives. This is where storytelling becomes strategic.
- Buying triggers & priorities:
Leaders don’t invest in tools because they sound clever. They invest when they help them make better decisions, act earlier, and see what others can’t. Real impact comes from insight that feels both credible and human.
- Narrative Capture
This is where SenseMaker Platform changes the game. Rather than forcing experiences into pre-defined boxes, it enables people to share their own stories and interpret their meaning themselves. This creates authentic, 𝐩𝐚𝐭𝐭𝐞𝐫𝐧-𝐫𝐢𝐜𝐡 𝐝𝐚𝐭𝐚 that helps leaders act with confidence in complexity.
.
If your employeeengagement tools or customersurveys are giving you numbers without meaning, SenseMaker Platform can help you surface what your dashboards miss: the lived experiences shaping performance, trust and change.
States in the external purpose line
From a tool claiming to support "What are Frameworks?"
Application Portfolio Management
- Where 👁 Manage your Application Portfolio in one solution. Perform Lifecycle Assessment, T.I.M.E. Analysis, and improve your data quality on an ongoing basis.
- How 👁 Align your investment portfolio with capability maps to better connect strategic goals and critical functions.
- What 👁 With single source of truth, manage your master data to make business impact decisions, and ensure business continuity
- Which 👁 Map your Business Processes, gain holistic overview of which processes support which value streams and business capabilities.
- When 👁 With our Information Objects, you can track your master flows through various integrations, and ensure ongoing GDPR compliance.
- Who 👁 Track your ideas to form initiatives from creation until approved state as visualised on digital roadmaps.
Changing states with the States in the external purpose line
- Plan (How) 👁 A digital knowledgebase for managing architecture processes, storing metadata, and ensuring transparency.
It supports decision-making, connects silos in a digital ecosystem, and provides governance.
Enterprise Architects oversee it, managing terms and keeping knowledge assets clear and accessible.
- Do (what) 👁 Strategic Planning to empower Business Architects to set strategic goals by aligning current Capabilities with future objectives through gap analysis.
This approach supports transformation planning, driving informed decisions and goal-focused change by integrating Business Architecture.
- Check (Which) 👁 Applications and Technology optimisation Helps optimise Applications and Technology by working with architects to simplify and standardise Processes.
With a focus on stability, these efforts improve efficiency and support long-term growth and transformation. With strong support for APM and standard management.
- Act (when) 👁 Capabilities for Portfolio Planning, combining strategic, tactical, and operational initiatives.
Optimisable gate-process ensures value creation aligned with strategic goals, not just cost allocation.
Also allowing Solution Architects to share their designs with each initiative.
What are Frameworks?
PEST analysis was developed in 1967 by Francis Aguilar as an environmental scanning framework for businesses to understand the external conditions and relations of a business in order to assist managers in strategic planning.
t has also been termed ETPS and other letter variants natanalysis.
A PESTLE analysis is a strategic management framework used to identify and analyze the key external macro-environmental factors—Political, Economic, Social, Technological, Legal, and Environmental—that can impact an organization. By examining these external forces, businesses can understand their broader operating environment, identify potential opportunities and threats, and make more informed strategic decisions to adapt and improve their performance.
Advantages:
- It's a simple framework.
- It facilitates an understanding of the wider business environment.
- It encourages the development of external and strategic thinking.
- It can enable an organisation to anticipate future business threats and take action to avoid or minimise their impact.
- It can enable an organisation to spot business opportunities and exploit them fully.
Disadvantages:
- Some PESTLE analysis users oversimplify the amount of data used for decisions, it's easy to use insufficient data.
- The risk of capturing too much data may lead to "paralysis by analysis".
- The data used may be based on assumptions that later prove to be unfounded.
- The pace of change makes it increasingly difficult to anticipate future developments that may affect an organisation.
- To be effective, the process needs to be repeated on a regular basis.
The Six Factors of a PESTLE Analysis
- What ➡Social: This refers to societal trends, cultural factors, and demographic shifts, including customer beliefs, customs, and lifestyle changes.
- How ➡Technological: This factor focuses on technological advancements and innovation, such as new internet usage habits, automation, and research and development.
- Where ➡Political: This factor examines government policies, stability, and regulations, such as tax policies, trade restrictions, and political climate.
- Who ➡Legal: This considers the impact of laws and legislation, including employment laws, consumer protection laws, and industry-specific regulations.
- When ➡Economic: This includes factors like economic growth or decline, interest rates, exchange rates, inflation, and unemployment rates.
- Which ➡Environmental: This encompasses ecological factors and environmental concerns, like climate change, natural resource availability, and the increasing demand for sustainable business practices.
Positive actions in transformations
How to Conduct a PESTLE Analysis
- Define the scope: Determine which factors are most relevant to the specific business or industry you are analyzing.
- Gather information: Collect credible data and information for each of the PESTLE factors from various sources.
- Analyze trends: Identify major trends within each category and how they might present opportunities or threats to the organization.
- Brainstorm insights: Conduct a brainstorming session to discuss and identify the key opportunities and threats arising from the analysis.
- Integrate into strategy: Use the insights from the PESTLE analysis to inform strategic decision-making and adapt business strategies to capitalize on opportunities and mitigate risks.
The goal and the flow stability
These are more advanced and tailored to complex organizational and ICT systems, but they still follow the same principle: structured progression through stages of
- Kotter's 8 Steps - Not an acronym, but a staged model - Organizational change management
- 5D Model - Discover Define Design Develop Deploy = Design thinking and innovation
- IDEAL - Initiating Diagnosing Establishing Acting Learning - SEI , ,
- A3 Thinking (Toyota) - Lean problem-solving and reporting
From SEI (software engineering institute)
Barriers to see:
- Initiating
Critical groundwork is completed during the initiating phase.
The business reasons for undertaking the effort are clearly articulated.
The effort's contributions to business goals and objectives are identified, as are its relationships with the organization's other work.
The support of critical managers is secured, and resources are allocated on an order-of-magnitude basis. Finally, an infrastructure for managing implementation details is put in place.
- Stimulus for change It is important to recognize the business reasons for changing an organization's practices.
The stimulus for change could be unanticipated events or circumstances, an edict from someone higher up in the organization, or the information gained from benchmarking activities as part of a continuous improvement approach.
- Set Context Once the reasons for initiating change have been clearly identified, the organization's management can set the context for the work that will be done.
"Setting context" means being very clear about where this effort fits within the organization's business strategy.
- Build Sponsorship Effective sponsorship is one of the most important factors for improvement efforts.
It is necessary to maintain sponsorship levels throughout an improvement effort, but because of the uncertainty and chaos facing the organization in the beginning of the effort, it is especially important to build critical management support early in the process.
- Charter Infrastructure Once the reason for the change and the context are understood and key sponsors are committed to the effort, the organization must set up a mechanism for managing the implementation details for the effort.
The infrastructure may be temporary or permanent, and its size and complexity may vary substantially depending on the nature of the improvement.
- Diagnosing Builds upon the initiating phase to develop a more complete understanding of the improvement work.
During the diagnosing phase two characterizations of the organization are developed: the current state of the organization and the desired future state.
- Characterize Current and Desired States Characterizing the current and desired states is similar to identifying the origin and destination of a journey.
Characterizing these two states can be done more easily using a reference standard such as the CMM for Software.
Where such a standard is not available, a good starting point is the factors identified as part of the "stimulus for change" activity
- Develop Recommendations The recommendations that are developed as a part of this activity suggest a way of proceeding in subsequent activities.
The diagnosing phase activities are most often performed by a team with experience and expertise relevant to the task at hand.
- Establishing The purpose of the establishing phase is to develop a detailed work plan.
Priorities are set that reflect the recommendations made during the diagnosing phase as well as the organization's broader operations and the constraints of its operating environment.
- Set Priorities The first activity of this phase is to set priorities for the change effort.
These priorities must take many factors into account: resources are limited, dependencies exist between recommended activities, external factors may intervene, and the organization's more global priorities must be honored.
- Plan Actions With the approach defined, a detailed implementation plan can be developed.
This plan includes schedule, tasks, milestones, decision points, resources, responsibilities, measurement, tracking mechanisms, risks and mitigation strategies, and any other elements required by the organization.
- Acting
- Create Solution The acting phase begins with bringing all available key elements together to create a "best guess" solution to address the previously identified organizational needs.
These key elements might include existing tools, processes, knowledge, and skills, as well as new knowledge, information, and outside help.
- Pilot/Test Solution Once a solution has been created, it must be tested, as best guess solutions rarely work exactly as planned.
This is often accomplished through a pilot test, but other means may be used.
- Refine Solution Once the paper solution has been tested, it should be modified to reflect the knowledge, experience, and lessons that were gained from the test.
Several iterations of the test-refine process may be necessary to reach a satisfactory solution. A solution should be workable before it is implemented, but waiting for a "perfect" solution may unnecessarily delay the implementation
- Implement Solution Once the solution is workable, it can be implemented throughout the organization.
Various roll-out approaches may be used for implementation, including top-down (starting at the highest level of the organization and working down) and just-in-time (implementing project-by-project at an appropriate time in its life cycle).
No one roll-out approach is universally better than another; the approach should be chosen based on the nature of the improvement and organizational circumstances.
- Learning The learning phase completes the improvement cycle. One of the goals of the IDEAL Model is to continuously improve the ability to implement change.
- Analyze and Validate This activity answers several questions: In what ways did the effort accomplish its intended purpose?
What worked well? What could be done more effectively or efficiently?
- Propose Future Actions During this activity, recommendations based on analysis and validation are developed and documented.
Proposals for improving future change implementations are provided to appropriate levels of management for consideration.
AK-3.6 Learning maturity from details by systems practical's
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
⟲ AK-3.6.1 Systems adding value, what are the values?
What are Frameworks?
Value Requirements (T.Gilb 2025)
Value Requirements are the most important requirements for any project.
They are the main purpose, and main justification, for a project.
They are the stakeholder's values.
Value requirements start life as value "attributes¨, needed by stakeholders.
No project can deliver all needed values, by a deadline.
No project will find all stakeholder values to be worth delivering.
So all value requirements start life by being acknowledged as possible delivery candidates.
But VRs need to go through an evaluation process to determine that we can prioritize them for real delivery.
⟲ AK-3.6.2 SSystems thinkning and lean: duality not a dichotomy
reflections on how lean really works
Value Requirements (T.Gilb 2025)
Because lean thinking is a study of challenges and responses, it’s really a study of how we define challenges together and how we build responses together, according to each person’s unique perspective, interests and special insights. To a large extent, lean thinking is not just a science of improvement, but also a science of building stronger teams.
Lean is not for everyone. Not because it’s particularly mysterious or complicated, but because it requires four deep commitments: to face our challenges in order to find more value to deliver; to be disciplined in our responses, both with routine problems and new, unexpected ones; to self-train and learn what we have to learn in order to succeed at responding to our challenges (which, in lean, men ans accepting to follow a sensei where and when he or she points the way); and to do it all together.
It’s easy to mistake the lean system for a toolbox: apply this tool to this problem and things will automatically improve. It’s equally easy to fall into the opposite extreme and think that coaching doesn’t require the constraints of the TPS (or cherry-picking your favorite aspect of the system as the only you need – hint: it’s a system!). In truth, the system is a concrete, hands-on theory of improvement that helps the sensei to find which exercise will make you progress right now (just as the sensei will progress in his or her understanding of the system itself).
Lean is a self-development method, not an organizational framework. And yes, we all have good days and bad days.
Sometimes we think the work is good enough (why can’t customers see how hard I work and how difficult it is, for a change?).
Sometimes we’re under pressure to cut corners, and then to cover up cutting corners. Sometimes, we simply can’t be bothered to challenge habits.
And that’s ok. The point of a lean system is that it remains there for us when we want to get back on the bike and keep climbing up the learning curve – no matter how often we fall. The deeper learning is always right behind the lesson we currently struggle with. Which is also what makes it endlessly fun.
⟲ AK-3.6.3 Learning from AI trying to improve complex frameworks
Addtional rules for ZARF:
- Visible dependencies and safe sequences
- Closed, bounded feedback loops
- Clear choreography of multi-cell changes
- Policy enforcement and auditability
- Temporal coherence across Now/Near/Far horizons
- Robust exception handling
Together, they turn ZARF into a fully governed, enterprise-grade reference frame for managing complexity end-to-end.
Traditional reference models (like Zachman) lacked the depth to handle human values, systemic tensions, and adaptive governance. These sections diagnose what was missing.
Identified Conceptual Gaps - ZARF Response attempt to resolve:
- Human Motivation No modeling of safety, honor, fame, or trust - ZARF_XPOS (Sociology)
- Legitimacy & Feedback No feedback-based trust or social adaptation - (ZARF_VIRU + ZARF_XPOS)
- Uncertainty Handling No fuzzy logic or refutation criteria - ZARF_VIRU (Neurology)
- Systemic Dualities No modeling of internal/external tensions - ZARF_STRC + ZARF_INTR
- Governance Complexity No unified taxonomy of rules and constraints - ZARF_VIRU
- Cultural Adaptation No support for evolving social norms - ZARF_XPOS
- Time Sensitivity No phased transformation logic - ZARF_STRC + ZARF_VIRU
⟲ AK-3.6.4 Learning from AI trying to understand complex systems
The world is a continuum.
46 lessons (I learned about system thinking, Ron Immink )
There are no separate systems.
Everything we think we know about the world is a model.
Every word and every language is a model. All maps and statistics, books and databases, equations and computer programs are models.
So are the ways you picture the world in your head, your mental models. None of these is or ever will be the real world.
Once we see the relationship between structure and behaviour, we can begin to understand how systems work, what makes them produce poor results, and how to shift them into better behaviour patterns.
These behaviour-based models are more useful than event-based ones, but they have fundamental problems.
They typically overemphasise system flows and underemphasize stocks.
The lessons I picked up:
- Because of feedback delays within complex systems, by the time a problem becomes apparent, it may be unnecessarily difficult to solve. A stitch in time saves nine.
- Don't put all your eggs in one basket.
- Systems happen all at once.
- The behaviour of a system cannot be known just by knowing the elements of which the system is made.
- When a living creature dies, it loses its "systemness".
- Elements do not have to be physical things. Intangibles are also elements of a system.
- Once you start listing the elements of a system, there is almost no end to the process.
- Many of the interconnections in systems operate through the flow of information. Information holds systems together and plays a great role in determining how they operate.
- Purposes are deduced from behaviour, not from rhetoric or stated goals.
- Keeping sub-purposes and overall system purposes in harmony is an essential function of successful systems.
- A system generally goes on being itself, changing only slowly if at all, even with complete substitutions of its elements, as long as its interconnections and purposes remain intact.
- The least obvious part of the system, its function or purpose, is often the most crucial determinant of the system's behaviour.
- A change in purpose changes a system profoundly, even if every element and interconnection remains the same.
- Interconnections are also critically important. Changing relationships usually change system behaviour.
- Stock is the foundation of any system. Stocks are the elements of the system that you can see, feel, count, or measure at any given time.
- A stock is the memory of the history of changing flows within the system.
- Stocks generally change slowly, even when the flows into or out of them change suddenly. Therefore, stocks act as delays or buffers or shock absorbers in systems.
- Changes in stocks set the pace of the dynamics of systems.
- The time lags that come from slowly changing stocks can cause problems in systems, but they also can be sources of stability.
- The presence of stocks allows inflows and outflows to be independent of each other and temporarily out of balance with each other.
- Human beings have invented hundreds of stock-maintaining mechanisms to make inflows and outflows independent and stable.
- Most individual and institutional decisions are designed to regulate the levels in stocks.
- Systems thinkers see the world as a collection of stocks along with the mechanisms for regulating the levels in the stocks by manipulating flows.
- The information delivered by a feedback loop can only affect future behaviour; it can't deliver the information, and so can't have an impact fast enough to correct the behaviour that drove the current feedback.
- Complex behaviours of systems often arise as the relative strengths of feedback loops shift, causing first one loop and then another to dominate behaviour.
- Delays are pervasive in systems, and they are strong determinants of behaviour. Changing the length of a delay may (or may not, depending on the type of delay and the relative lengths of other delays) make a large change in the behaviour of a system.
- Whenever we see a growing entity, whether it be a population, a corporation, a bank account, a rumour, an epidemic, or sales of a new product, we look for the reinforcing loops that are driving it and for the balancing loops that ultimately will constrain it.
- A quantity growing exponentially toward a constraint or limit reaches that limit in a surprisingly short time.
- When a subsystem's goals dominate at the expense of the total system's goals, the resulting behaviour is called suboptimisation.
- When a systems thinker encounters a problem, the first thing he or she does is look for data, time graphs, the history of the system.
- Systems rarely have real boundaries.
- The greatest complexities arise exactly at boundaries.
- You can often stabilise a system by increasing the capacity of a buffer.
- We are too fascinated by events. We pay too little attention to their history.
- Rebuilding is the slowest and most expensive kind of change to make in a system.
- Things take as long as they take.
- Missing information flows is one of the most common causes of system malfunction.
- Paradigms are the sources of systems.
- The physical structure is crucial in a system, but is rarely a leverage point, because changing it is rarely quick or simple.
- Disorderly, mixed-up borders are sources of diversity and creativity.
- Changing the length of a delay may utterly change behaviour.
- Change comes first from stepping outside the limited information that can be seen from any single place in the system and getting an overview.
- We don't give all incoming signals their appropriate weights
- Remember that hierarchies exist to serve the bottom layers, not the top.
- Thou shalt not distort, delay, or withhold information.
- Power over the rules is real power.
Systems need to be managed not only for productivity or stability, but they also need to be managed for resilience.
Resilience is the ability to bounce or spring back into shape, position, etc., after being pressed or stretched.
The ability to recover strength, spirits, good humour, or any other aspect quickly. is a measure of a system's ability to survive and persist within a variable environment.
The opposite of resilience is or rigidity. There are always limits to resilience.
The goal and knowledge stability
On this site references to frameworks like JABES, JABSA, and SIMF, which extend traditional cycles with deeper abstraction layers.
These integrate:
- CES: Strategic, Tactical, Operational enterprise processes
- CPI: Controlled innovation and change
- CTO: Technology build, run; devops cycle
- 6*6 Reference Framework: A multidimensional matrix for systems thinking, combining perspectives like What, Why, How, When, Where, Which across internal and external flows
These are more advanced and tailored to complex organizational and ICT systems, but they still follow the same principle: structured progression through stages of
- understanding,
- planning,
- acting, and
- refining.
  
  
  
© 2012,2020,2024 J.A.Karman