Browser Playground & VS Code Extension

ArgBlazer explores decision landscapes using argumentation frameworks.

ArgBlazer lets you construct an argumentation framework (AF) incrementally, step forward and backward through the construction, and watch the extensions and decision outcomes update at every step.

Try the Playground Install for VS Code

Key features

Interactive graph visualization

PlaygroundVS Code

Generates an interactive HTML report from YAML describing an argumentation framework—typed interactively in the playground editor, or read from a file in VS Code—displayed side by side with the YAML.

Extensions

PlaygroundVS Code

Automatically computes and displays conflict-free, admissible, complete, preferred, grounded, and stable extensions.

Step-by-step construction

PlaygroundVS Code

Construct an AF incrementally by adding arguments and attacks, and step forward and backward through the construction to observe how each argument affects the extensions and decision outcomes.

Cases

PlaygroundVS Code

Assign arguments to named cases and show only the arguments belonging to selected cases, with extensions and decisions recomputed accordingly.

Decisions

PlaygroundVS Code

Declare decisions of interest and specify how each answer is extracted from the AF via a criterion, a quantifier, and a choice of semantics; answers update automatically at every step.

Argument labeling

PlaygroundVS Code

Selecting an extension colors each argument by its label, with a legend below the graph—In and Not in by default, and a checkbox to distinguish out and undec.

Graph layout control

PlaygroundVS Code

Anchor annotations control which arguments are placed at the top or bottom of the graph layout.

Zoom controls

PlaygroundVS Code

Zoom in, zoom out, and fit-to-view buttons on the graph.

Live reload

PlaygroundVS Code

In VS Code, the report updates automatically whenever the YAML file is saved. In the playground, press Cmd+S (Mac) or Ctrl+S (Windows/Linux) to apply your changes in the browser.

Shareable URLs

Playground

The browser playground encodes your framework in the URL, so any exploration can be shared as a link.

Export to HTML

VS Code

Right-click the report panel and select "Export as HTML" to save as a standalone HTML file.

Examples

Step-by-step construction

Arguments are introduced incrementally across steps, with the extensions recomputed at each step.

YAML

ARGUMENTS:
  a:
    step: 1
  b:
    step: 1
  c:
    step: 2
  d:
    step: 3
ATTACKS:
  b: [a]
  c: [b]
  d: [c]

Step 1

graph BT
  classDef default fill:#D5E8D4,stroke:#000000
  classDef ghost fill:transparent,stroke:none,color:transparent
  subgraph r2[Rank 2]
    b
  end
  subgraph r1[Rank 1]
    a
  end
  class r1,r2 ghost
  b --> a

Step 2

graph BT
  classDef default fill:#D5E8D4,stroke:#000000
  classDef add fill:#D5E8D4,stroke:#000000,stroke-width:4px
  classDef ghost fill:transparent,stroke:none,color:transparent
  subgraph r3[Rank 3]
    c
  end
  subgraph r2[Rank 2]
    b
  end
  subgraph r1[Rank 1]
    a
  end
  class r1,r2,r3 ghost
  b --> a
  c ==> b
  class c add

Step 3

graph BT
  classDef default fill:#D5E8D4,stroke:#000000
  classDef add fill:#D5E8D4,stroke:#000000,stroke-width:4px
  classDef ghost fill:transparent,stroke:none,color:transparent
  subgraph r4[Rank 4]
    d
  end
  subgraph r3[Rank 3]
    c
  end
  subgraph r2[Rank 2]
    b
  end
  subgraph r1[Rank 1]
    a
  end
  class r1,r2,r3,r4 ghost
  b --> a
  c --> b
  d ==> c
  class d add

Top / bottom layout

Annotations control which arguments are placed at the top or bottom of the graph.

YAML

ARGUMENTS:
  a:
    anchor: top
  b:
  c:
  d:
    anchor: bottom
  e:
    anchor: bottom
ATTACKS:
  b: [a]
  c: [b]
  d: [c]
  e: [b]

Rank from top

graph BT
  classDef default fill:#D5E8D4,stroke:#000000
  classDef ghost fill:transparent,stroke:none,color:transparent
  subgraph r4[Rank 4]
    d
  end
  subgraph r3[Rank 3]
    c
    e
  end
  subgraph r2[Rank 2]
    b
  end
  subgraph r1[Rank 1]
    a
  end
  class r1,r2,r3,r4 ghost
  b --> a
  c --> b
  d --> c
  e --> b

Rank from bottom

graph BT
  classDef default fill:#D5E8D4,stroke:#000000
  classDef ghost fill:transparent,stroke:none,color:transparent
  subgraph r1[Rank 1]
    d
    e
  end
  subgraph r2[Rank 2]
    c
    b
  end
  subgraph r3[Rank 3]
    a
  end
  class r1,r2,r3 ghost
  b --> a
  c --> b
  d --> c
  e --> b

Decisions

Decisions pose yes/no questions about the argumentation framework; each is answered against the computed extensions and updates at every step.

YAML

ARGUMENTS:
  dine-in:
  to-go:
  soggy:
  fryer:
ATTACKS:
  to-go: [dine-in]
  dine-in: [to-go]
  soggy: [to-go]
  fryer: [soggy]
DECISIONS:
  "Can we get fried chicken to go?":
    criterion: to-go
    quantifier: at least one
    semantics: preferred
  "Must we get fried chicken to go?":
    criterion: to-go
    quantifier: all
    semantics: preferred

Preferred {to-go, fryer} selected

graph BT
  classDef default fill:#D5E8D4,stroke:#000000
  classDef in fill:#0F7C0F,stroke:#000000,color:#ffffff
  din["dine-in"]
  tog["to-go"]
  sog["soggy"]
  fry["fryer"]
  tog --> din
  din --> tog
  sog --> tog
  fry --> sog
  class tog,fry in

Preferred {dine-in, fryer} selected

graph BT
  classDef default fill:#D5E8D4,stroke:#000000
  classDef in fill:#0F7C0F,stroke:#000000,color:#ffffff
  din["dine-in"]
  tog["to-go"]
  sog["soggy"]
  fry["fryer"]
  tog --> din
  din --> tog
  sog --> tog
  fry --> sog
  class din,fry in

Can we get fried chicken to go? Yes, it is the case that the criterion to-go holds in at least one preferred extension.

Must we get fried chicken to go? No, it is not the case that the criterion to-go holds in all preferred extensions.

Argument labeling

Clicking an extension highlights the arguments it contains. By default the graph shows two colors—In and Not in; ticking "Distinguish Out/Undec" in the legend splits "Not in" into out (attacked by a member) and undec (neither).

Grounded {fryer} selected — default

graph BT
  classDef in fill:#0F7C0F,stroke:#000000,color:#ffffff
  classDef notin fill:#D5E8D4,stroke:#000000
  din["dine-in"]
  tog["to-go"]
  sog["soggy"]
  fry["fryer"]
  tog --> din
  din --> tog
  sog --> tog
  fry --> sog
  class fry in
  class din,tog,sog notin

Grounded {fryer} selected — "Distinguish Out/Undec" ticked

graph BT
  classDef in fill:#0F7C0F,stroke:#000000,color:#ffffff
  classDef out fill:#D5E8D4,stroke:#000000
  classDef undec fill:#FFFFFF,stroke:#000000
  din["dine-in"]
  tog["to-go"]
  sog["soggy"]
  fry["fryer"]
  tog --> din
  din --> tog
  sog --> tog
  fry --> sog
  class fry in
  class sog out
  class din,tog undec

In the grounded extension {fryer}, soggy is out (attacked by fryer) while dine-in and to-go remain undecided (they only attack each other). Each theme gives the three labels distinct colors—Green: in (dark green), out (light green), undec (white); XRAY: in (blue), out (orange), undec (yellow).

YAML Structure

ArgBlazer reads YAML files with these top-level fields.

Field names are case-insensitive: exhibit, Attacks, etc. are accepted as well.

Field	Required	Type	Description
`EXHIBIT`	No	String	Context information displayed in the Exhibit section
`ARGUMENTS`	Yes	Mapping	Argument definitions, keyed by argument ID (e.g. `a`, `to-go`). The ID labels the node in the graph and is referenced in `ATTACKS` and in a decision's `criterion`. An ID cannot begin with `~`, which is reserved to mark exclusion in a decision's `criterion`. Arguments may also include the annotations below.
`ATTACKS`	No	Mapping	Attack relationships from attacker to targets, e.g. `b: [a]` means b attacks a. A single target may also be written without brackets: `b: a`
`DECISIONS`	No	Mapping	Yes/no questions keyed by question text; each has a `criterion` — an argument ID, or a list of them, where a `~` prefix excludes an argument and the terms combine conjunctively (`[b, ~c]` means "contains b and not c") — a `quantifier` (`at least one`, `all`, or `none`), and a `semantics` type (`conflict_free`, `admissible`, `complete`, `preferred`, `grounded`, or `stable`)

Argument annotations

Annotation	Type	Description
`summary`	String	Brief description shown on graph nodes
`details`	String or list	Extended details as a list of key-value pairs with arbitrary sub-fields (e.g. rule, evidence, conclusion)
`step`	Integer	Which step the argument is introduced (for incremental construction)
`anchor`	String	Place this argument at the top or bottom of the graph layout (`top` or `bottom`)
`cases`	List	The named cases this argument belongs to, used for filtering arguments. The scalar `all` is a reserved wildcard meaning every named case in the file (a list such as `[all]` is a literal case named "all")