⬡ The Hive Diagram Pipeline

The Hive Diagram Pipeline

A shared language for modelers and non-modelers.

What is it? Contact Us

About

The Hive Diagram (HD) Pipeline provides a visual methodology for conceptualizing Agent-Based Models (ABMs) and Multi-Agent Simulations (MAS) before computational implementation. By translating established modelling concepts into a shared visual language, it enables modelers and non-modelers to collaboratively explore model structures, assumptions, interactions, and mechanisms.

Hive Diagram cards

The Pipeline is guided by three principles:

  • Conceptual simplicity: Makes simulation modelling more accessible by organizing established modelling concepts into intuitive visual components (HD Cards), without compromising scientific complexity or introducing new modelling concepts.
  • Methodological rigor: Complements existing simulation methodologies by connecting visual conceptualization with formal documentation protocols, particularly the ODD (Overview, Design Concepts, and Details) protocol and Pattern-Oriented Modelling.
  • Iterative learning: Treats model conceptualization as an ongoing process in which assumptions, mechanisms, and model structures are continuously reviewed and refined as new evidence emerges and simulation results reveal unexpected behaviours.

Through these principles, the HD Pipeline bridges collaborative model exploration and formal simulation design, helping participants identify missing mechanisms, challenge assumptions, and develop a shared understanding of the processes underlying complex system behaviour.

The Hive Diagram

Thinking through the cards.

Instructions

Publications

Introduction to the publications.

Manifesto

Simulation starts as a conversation, not as code. Before a model runs, people have to agree on what it is about. That agreement should be something anyone can build, question and revise by hand.

  • Everyone belongs at the table. Everyone who knows the system matters. Domain experts, communities, policymakers and students hold knowledge that models need. Technical vocabulary should never be the price of admission.
  • Talk about why before how. Keep modelling jargon to a minimum, so the discussion is about why a process matters, not how to encode it.
  • Objects can be moved. Ideas written on cards can be rearranged, challenged and replaced. Physical, analogue handling makes abstract concepts workable.
  • There is no single way in. Start from an agent, a pattern, an environment or an intervention. Any entry point converges on the same connected network.
  • Begin with what we can observe. Patterns come first, and mechanisms are inferred from them. Models do not simulate patterns; they simulate the entities that produce them.
  • Complement the standards. The cards precede ODD, follow the logic of Pattern-Oriented Modelling and end in pseudocode a developer can implement. Existing protocols are not replaced.
  • Every line traces to a card. What the cards say becomes the documentation, and what they do not say is flagged. Gaps are never invented away.
  • A diagram is a living artefact. Refine it as code, results and evidence arrive, instead of discarding it once programming begins.
  • Keep it open. Instructions, examples and materials are free to use with attribution.

The goal is not to make everyone a modeller. It is to make modelling something anyone can begin.

Workshops

The aim of our workshops is to introduce the key principles of simulation and help participants, regardless of their experience or role, translate discussions into agent-based models.

Our workshops have different objectives and offer opportunities to explore how to understand and conceptualise simulations, deconstruct existing models, or discover new approaches and ideas that could enrich your curriculum.

Explore our workshops and acces the materials available for each workshop type.

Case Studies

Introduction to the case studies.