IBIS Argument Map

Why it matters

An IBIS map — short for Issue-Based Information System — draws a debate the way it actually works: a question gets raised, people propose answers, and each answer collects reasons for and against it. The map has three kinds of node. An issue is a question that opens the conversation (marked with a ”?”). Positions are the candidate answers to that issue. Arguments are the reasons that support a position (pro) or object to it (con). Its whole job is to turn a sprawling, circling discussion into a structure you can see — so you can tell what’s actually in dispute, which answer is responding to which question, and what holds each answer up.

For example: a team argues for three weeks about whether to adopt Kubernetes, and the conversation never converges. Drawn as an IBIS map, the reason becomes obvious in one glance — the root issue had quietly split in two. Half the room is answering “how do we fix our operational pain?” and the other half is answering “is our pain even an infrastructure problem?” Two different issues, two different sets of positions, arguments aimed past each other. The map didn’t settle the debate. It showed the team they’d been having two debates and mistaking them for one.

  • What it shows. A deliberation as a branching structure: the question at issue, the positions that answer it, and the pro and con arguments hanging off each — every claim tagged with the role it plays.
  • When to reach for it. A messy, multi-sided debate or a design-rationale conversation where several answers are on the table and the reasons for and against each need to be visible at the same time.
  • How to read it. Start at the issue (the question), follow each position (a candidate answer) down to its arguments, and read pro and con together — a position with three cons and no pros is in trouble; an issue with no positions is an open question nobody has answered yet.
  • What you’d miss without it. The shape of the disagreement. In flowing prose, a shifted question or a position with no support reads like just more text; on the map it’s a structural gap you can point at.
  • Where it misleads. A tidy map can look settled when it isn’t — the arguments are still claims, not verdicts — and an honest IBIS map stays small; one that sprawls to hundreds of nodes is usually mixing levels or failing to merge claims that say the same thing.

How to read it

Picture a question at the top of the page with answers branching beneath it. That top question is the issue — the thing actually in dispute, stated as a question and marked with a ”?” (“Should we adopt Kubernetes?” not “Kubernetes”). Branching off the issue are the positions: the candidate answers, the responses anyone has put forward (“yes, migrate everything,” “no, fix the CI pipeline first,” “adopt it for new services only”). And hanging off each position are the arguments — a pro is a reason that supports that position, a con is a reason that objects to it. Read a position together with its pros and cons and you see not just what someone proposed but how well it stands up.

The structure grows as the debate deepens. A new question rarely arrives alone at the top — it usually surfaces out of a position or an argument, the way “but who would own the new platform?” springs from the position “let’s stand up a platform team.” So a fresh issue branches off whatever raised it, carrying its own positions and arguments down a new limb. That branching is the point: it preserves the history of how the conversation evolved, so you can trace today’s live disagreement back to the turn that spawned it.

Reading the map back, you get what a transcript can never give you at a glance. The issues tell you what’s genuinely contested. The positions under each issue tell you which answers are responding to which question — and catch the classic failure where two people argue hard while answering different questions. The pros and cons tell you what supports each answer and where the weight of reasons actually sits. A tangled hour of back-and-forth compresses to a structure you can scan in a minute: not a record of everything said, but a map of what’s in dispute and why.

When to use it

The IBIS map belongs to the ARGUMENT family of diagrams — the ones that make the structure of reasoning visible — and within that family it is the deliberation tool: the one you reach for to untangle a messy, multi-sided debate or to capture design rationale as a conversation unfolds (the practice called dialogue mapping). That places it next to three relatives, and knowing the boundaries is how you pick the right tool:

  • The Argument Audit (a Toulmin-style breakdown) zooms into one argument’s anatomy — its claim, the grounds, the warrant connecting them, and the rebuttals. Reach for it when you want to test whether a single line of reasoning actually holds; reach for IBIS when you want the shape of the whole debate.
  • A Pro-Con Tree lays out one decision’s case — the pros and cons of a single choice, two columns. IBIS generalizes it: many candidate positions answering a question, not one option weighed up.
  • A Concept Map captures how ideas relate — knowledge, the conceptual lay of a domain — not how a deliberation is structured. IBIS is about who-argued-what; a concept map is about how-things-connect.

Reach for an IBIS map when several answers are genuinely on the table, the reasons for and against each need to sit side by side, and the conversation is long or circling enough that people are losing track of what’s been said. Skip it when there’s really one decision with two sides (use a pro-con tree), when you need to scrutinize a single argument’s logic (use the argument audit), or when you’re mapping a body of knowledge rather than a dispute (use a concept map). IBIS is the tool for the live, contested middle — the deliberation still in motion.

How Ora builds it

Ora produces an IBIS map from a semantic spec — a structured description of the issues (the questions at stake), the positions that respond to each issue, the pro and con arguments attached to each position, and the typed links that connect them (a position responds to an issue, a pro supports a position, a con objects to one, and a new issue branches off whatever raised it). That spec is rendered to a diagram in the Compendium style the IBIS tradition established (the layout engine arranges issues at the top, positions beneath, arguments hanging from positions, and follow-up issues threading back to their origin; node colour and a glyph encode the role — a ”?” for issues, a ”+” for pros, a ”−” for cons), and it ships with an outline view and alt-text, since a colour-and-glyph graph alone isn’t accessible.

The diagram is the visual face of Ora’s argument-analysis and facilitation work: when you ask it to “map this debate” or “give me the issues, positions, and arguments in this discussion,” that mode runs the typing discipline — every claim tagged as an issue, a position, a pro, or a con — and this artifact is how it shows the structure it found. It’s best used live, growing as the conversation generates new turns, rather than drawn once over a finished argument.

The technique is the work of Werner Kunz and Horst Rittel, who set out IBIS in their 1970 working paper Issues as Elements of Information Systems — Rittel being the design theorist who coined the term “wicked problem” for exactly the kind of dispute that has no single right answer but does have a recoverable structure. It was implemented in software through the 1980s (gIBIS, then the Compendium project), and Jeff Conklin turned it into a real-time facilitation practice he named dialogue mapping, the canonical practitioner’s reference for using IBIS to build shared understanding around wicked problems.

  • Pro-Con Tree — the ARGUMENT family’s single-decision tool: the pros and cons of one choice, which IBIS generalizes to many positions answering a contested question.
  • Concept Map — maps how ideas relate (knowledge and conceptual structure) rather than how a deliberation is argued; the contrast that keeps an IBIS map about rhetorical roles, not subject-matter links.
  • Flowchart — models a process, a sequence of steps and decisions, not an argument; the boundary that keeps IBIS focused on what’s in dispute rather than what happens next.
  • Argument Audit (mode) — the Toulmin-style breakdown of a single argument’s anatomy; the close-up companion to IBIS’s wide-angle view of the whole debate.