Comprehensive Simulation Meta Model for Transition Planning and Decision Analysis with Sustainable Impact

Abstract

A comprehensive simulation meta model for transition planning and decision analysis is proposed and outlined. This model is designed to provide insight on the effects of a proposed agenda ahead of time, and to support an optimization of means and resources available to decision makers in governments, organizations, businesses, or to private persons to reach their goals across different time horizons and considering different quantities of relevance.

The model supports multiple use cases. The system of interest, the decision makers, the nature of the decisions to be made, and the quantities relevant to the decision makers do not need to be defined a priori. The results of the simulation can be aggregated onto diverse observables relevant for business, economy, society, and environment.

The meta model is modular, combining existing domain-specific models into one framework. It will gradually be extended to cover all domains and scales relevant for sustainable business, sustainable finance, and sustainable development.

The article outlines the approach and gives examples of applications. It also shows how the model will gradually be developed during its application, allowing a targeted and fast application while allowing continuous learning and improvement.

Appendix

1.1 Terminology and Key Term Definitions

Term	Description	Examples	Section	Belongs to
Model method	The model method categories classify the model by how it works	System dynamics, statistical static, judgmental scenario-based	(see parts of model method)
Model coverage	The model coverage categories classify the model by the scope of the system it covers, i.e., by what is contained in the system	Economy of the United States of America	Model coverage: domain and scope
Model resolution	The model resolution categories classify the model by the level of detail it resolves the system into	Single companies, groups of people, cities	Granularity: controlling the computational cost
Scale	Order of magnitude of the system and the resolution of detail	Macro, meso, micro, nano	Scale
Specificity level	Specificity of the model approach can reach. This dimension covers the spectrum between top-down and bottom-up modeling. There are three levels: systems, agents, and individuals	System dynamics, agent-based model	Synthesis by model specificity	Resolution, method
Technique	Technique employed to describe, simplify, and quantify the system to be understood	Structural model, statistical model, judgmental model	Synthesis of modelling techniques	Method
Degree of dynamic response	(define when writing the section)	Inelastic dynamic, elastic dynamic, scenario-based static	Degrees of dynamic response	Method, resolution
Domain	Subject matter area the model covers	Real economy, society, politics, climate	Synthesis of domains	Coverage
Scope	Coverage of the model in terms of size and location (spatial coverage)	City of Zurich, France, World	Scope: dimensions of spatial coverage	Coverage, scale
Granularity	Level of detail in terms of size the model resolves the system into	Cities (meso), companies (micro), employees (nano), square km	Granularity: controlling the computational cost	Resolution, scale
Level of attention	Methodological focus a sub-system receives in case of a partition into system and environment or a nested partition into system and environment: differentiated model specificity levels, granularities, degrees of dynamic response.	Split into Zurich (high specificity, fully dynamic, high granularity), Switzerland (low granularity), rest of world (low specificity, scenario-based static)	Levels of attention: system and environment
Boundary condition	Boundary conditions include both constraints (prior knowledge the simulation must observe) and the quantification of the impact the environment has on the system if the time evolution is not available from another part of the model.	Expert judgement on reasonable range of national GDP growth, time series of world’s output growth as a context for national GDP growth	Use and generation of data
Agenda	The agenda is a model input provided by the user and can consist of one-off actions or series of actions concerted over time	One-off investment capital redeployment, continually raised fuel economy standards	Special modules
Agenda variant	Agenda variants are mutually exclusive parameterizations of an agenda, used to find the optimum agenda to achieve the desired impact.	Fast-paced raise of fuel economy standard (as opposed to slow increase of one-off).	Special modules	Agenda
Issue chain	Series of high-level dependencies between issues which are deemed relevant, have a telling name. It has an overarching narrative and represents a selection from the high-level dependency graph at the systems level. Depending on the maturity level of the model part under consideration, the relevance of the individual dependencies might be hypothetical or proven.	The effect of the investment decision on the portfolio’s financial performance is directly determined by the expected relative financial performance of the two bonds affected by the decision.	Networks, the glue of the model	Network
Issue node	The issue node formalizes and quantifies an issue which is deemed relevant and has a telling name. It may carry one or many quantities or proxies of quantities. The issue node represents a node in the high-level dependency graph at the systems level.	Investment decision, economic performance, economic opportunities	Networks, the glue of the model	Network, issue chain
Issue link	A connection between two issue nodes. The issue link represents an edge in the high-level dependency graph at the systems level	Impact of liquidity provided by investment on the economic performance of a company	Networks, the glue of the model	Network, issue chain
Influence	The influence reflects a change to one or more properties of an entity in the system caused by an entity within or outside the system. It has a name, a direction, and an influence function. In system dynamics, it is often called flow. In agent-based modeling, it is often called rule. In network modeling, it is often called transaction.	Influence of microclimate on available fresh water, financial disruption caused by economic downturn, a customer purchasing a good, effect of a central bank “printing” money on liquidity available to banks, a supply relationship, company ownership relationship.	Time scales and degrees of dynamic response	Network
Influence function	The quantification of an influence, usually consisting of several parameters relating to the strength, timing (lag), and polarity (sign) of the influence.	Covariance and lag between defined open-market operations and loan cash reserves of business banks, high/medium/low assessment of the influence of a defined change of microclimate on the fresh water supplies as initial guess	Time scales and degrees of dynamic response	Network, influence
External influence	Influence on parts of the system from outside. In other communities also stress or perturbation.	Action (action module), influence of world economy on a country’s prosperity	Time scales and degrees of dynamic response	Network
Master source	A master source contains the sources of evidence behind a quantity used in the model. The sources of evidence are the endpoints of a data lineage, i.e., the ultimate sources.	Defined records in a data set, formally captured expert judgments in a database, original statements that can be referred to.	Use and generation of data	Data

1.2 Interaction Between Use Case and Model Development

Goals of the different use case delivery phases are:

• Pilot and prototype: speedy delivery of first insight with as little constraint as possible

• Prototype: constraint-free leverage of pre-existing model and

• Deliver and incorporate: continuous progress and innovation, sustainable and reproducible creation of results

Phase	Direction	Matter	Notes
Pilot, prototype	Model—use case	Base model as starting point	Experimentation
Prototype	Use case—model	Data for the public domain
Prototype	Use case—model	Insight and guidance for model extension	Including prioritization by importance
Prototype	Use case—model	Test cases, insight about back test
Prototype	Modely—use case	Continually improved and extended model
Prototype	Model—use case	Controlled framework	Repeatability, reproducibility, consistency

1.3 Model Artefacts

Name	Purposes	Priority	Description	Notes
High-level description	Get into the model, published reference	H	Description of the model for a knowledgeable person as a first reading	Publication in the Springer Book chapter in “theories of change”
Formal description	Establish the model in scientific world	M	Description satisfying standards of a peer-reviewed journal	Scientific publications
Model ontology	Guide through the details of the model graph	H	Gives a context for the details and outlines the model locators	Highlights implemented parts of full model and ensures consistency via the model locators
Domain entity model (model graph)	Formal reference language across the component models	H	Condensed formal description and specification of the entities in the model	Meta language and technical form need to be ready before details are worked out (migration is cumbersome)
Domain functional model	Formal reference language across the component models	H	Condensed formal description and specification of the functions in the model	Meta language and technical form need to be ready before details are worked out (migration is cumbersome)
Data catalogue	Find and re-use important information	H	According to established data catalogue standards	Form needs to be established early on
Domain data master sources	Resolve potential conflicts between data sets	M	A reference repository of data processed for model use and a reproducible methodology for refresh and update	Includes data lineage, tracing information back to all sources
Data backbone	Get the results in a reproducible, consistent way, allowing progress	L	Technical infrastructure for data brought into a common form	Follows the domain entity model
API specification	Establish a common reference for model integration	M	How the component models communicate with each other	Concept and proof of concept need to be established as soon as the domain model, follows the domain entity model
Model implementation	Get the results in a reproducible, consistent way, allowing progress	L	Meta model reference implementation, aspiration: can power even a game	Architectural artifacts need to be ready first