ArgBlazer
ArgBlazer is an interactive tool for exploring decision landscapes—the competing options, their supporting arguments and conflicts, and how each option fares as arguments are added or removed—using argumentation frameworks (AFs). The tool enables a user to construct an AF for making a determination by incrementally adding arguments and attacks, and to step forward and backward through the construction to observe how each argument affects the extensions and decision outcomes. Users can explore the implications of the AF and its extensions under various semantics at each step. ArgBlazer further provides means to declare decisions of interest and to specify, for each, how its answer is extracted from the AF, via a criterion, a quantifier, and a choice of semantics. Answers are updated automatically at every step for the user's consideration.
This VS Code extension generates the ArgBlazer report from a YAML file describing the AF, displays it side by side with the YAML in a webview panel, updates it automatically whenever the file is saved, and can export it as a standalone HTML file.
ArgBlazer is also available as a browser playground with shareable URLs—the same reports, running entirely client-side, no installation needed.
Features
- Interactive graph visualization — generates an interactive HTML report from a YAML file representing an argumentation framework, displayed in a side-by-side webview panel
- Extensions — automatically computes and displays conflict-free, admissible, complete, preferred, grounded, and stable extensions (powered by the afsolver package); clicking an extension highlights each argument as in (member of the extension), out (attacked by a member), or undecided
- Step-by-step construction — arguments can be introduced incrementally across steps, with the graph and extensions recomputed at each step (see Step-by-Step Construction)
- Cases — assign arguments to named cases and show only the arguments belonging to selected cases, with extensions and decisions recomputed accordingly (see Cases)
- Decisions — pose yes/no questions about whether an argument can or must appear in a given extension type (see Decisions)
- Argument labeling — when an extension is selected, each argument is colored by its label, with a legend below the graph. By default out and undec share a single "Not in" color; ticking the "Distinguish Out/Undec" checkbox in the legend switches to the full three-way labeling. Green theme: in (dark green), out (light green), undec (white); XRAY theme: in (blue), out (orange), undec (yellow)
- Graph layout control —
top and bottom annotations control which arguments are placed at the top or bottom of the graph layout (see Top and Bottom Layout)
- Zoom controls — zoom in, zoom out, and fit-to-view buttons on the graph
- Live reload — the report updates automatically whenever the YAML file is saved
- Export to HTML — right-click the report panel and select "Export as HTML" to save a standalone HTML file
Requirements
- A YAML file that represents an argumentation framework using the
ARGUMENTS key (required), and optionally the EXHIBIT, ATTACKS, and DECISIONS keys.
Usage
- Open a YAML file containing argumentation framework data in VS Code
- Click the "Generate ArgBlazer Report to the right" button (ArgBlazer icon) in the editor title toolbar (top-right corner)
- The HTML report will appear in a webview panel beside your YAML file
- Reports automatically update when you save changes to the YAML file
A YAML file contains the EXHIBIT (optional), DECISIONS (optional), ARGUMENTS (required), and ATTACKS (optional) keys. These key names are case-insensitive, so exhibit, Attacks, etc. are accepted as well:
EXHIBIT: |
Tweety is a bird.
Tweety is a penguin.
ARGUMENTS:
a:
summary: Tweety can fly because birds typically can fly
details:
rule: Birds typically can fly
evidence: Tweety is a bird
conclusion: Tweety can fly
b:
summary: Tweety cannot fly because it is a penguin
details:
rule: Penguins cannot fly
evidence: Tweety is a penguin
conclusion: Tweety cannot fly
ATTACKS:
b: [a]
Each key under ARGUMENTS (here a and b) is the argument's ID. 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 with no fields can be written with an empty value:
ARGUMENTS:
a:
b:
ATTACKS:
b: [a]
When an attacker has a single target, the brackets may be omitted: b: [a] can also be written as b: a.
When ATTACKS is omitted, the report displays the arguments as disconnected nodes.
Decisions
The DECISIONS key poses yes/no questions about whether a specific argument appears in a given extension. Each decision has three fields:
criterion: the argument to query, or a list of arguments. Prefixing an ID with ~ excludes it, so ~c asks that c be absent. A list combines conjunctively: [b, ~c] is satisfied by an extension that contains b and does not contain c.quantifier: at least one (the argument appears in at least one extension, default), all (it appears in every extension), or none (it appears in no extension)semantics: the extension type to query, one of conflict_free, admissible, complete, preferred, grounded, or stable (default: preferred)
ARGUMENTS:
a:
summary: Order fried chicken in
b:
summary: Get fried chicken to go
c:
summary: Fried chicken to go will not be crispy
d:
summary: An air fryer at home can make fried chicken crispy
ATTACKS:
b: [a]
a: [b]
c: [b]
d: [c]
DECISIONS:
"Can we get fried chicken to go?":
criterion: b
quantifier: at least one
semantics: preferred
"Must we get fried chicken to go?":
criterion: b
quantifier: all
semantics: preferred
The Decisions panel appears in the report when DECISIONS is present, showing each question with a Yes or No answer that updates as you navigate steps.
Cases
The cases annotation assigns an argument to one or more named cases. Arguments without a cases annotation are treated as "unassigned" and can be shown or hidden separately via the dropdown. You can choose to show only the arguments belonging to selected cases; extensions and decisions are recomputed accordingly.
The scalar cases: all is a reserved wildcard: the argument belongs to every named case in the file, so it is shown whenever any case is selected. Only the bare scalar is reserved—a list such as cases: [all] denotes a literal case named "all". Note that all does not introduce cases by itself: a case appears in the dropdown only if at least one argument names it explicitly.
ARGUMENTS:
a:
summary: Order fried chicken in
cases: all
b:
summary: Get fried chicken to go
cases: all
c:
summary: To-go chicken will be soggy
details:
rule: Food transported in a box loses crispiness due to trapped steam
evidence: Fried chicken taken to go is transported in a box
conclusion: To-go chicken will be soggy
cases:
- apartment without air fryer
- apartment with air fryer
d:
summary: An air fryer at home can make fried chicken crispy
details:
rule: An air fryer restores crispiness by circulating hot air
evidence: There is an air fryer at home
conclusion: An air fryer at home can make fried chicken crispy again
cases:
- apartment with air fryer
ATTACKS:
b: [a]
a: [b]
c: [b]
d: [c]
Step-by-Step Construction
Arguments can be introduced incrementally using the step annotation. The graph is built up step by step—each step shows all arguments introduced up to that point, along with any attacks between them. Use the navigation buttons in the report to move between steps.
ARGUMENTS:
a:
step: 1
b:
step: 1
c:
step: 2
d:
step: 3
ATTACKS:
b: [a]
c: [b]
d: [c]
In this example, step 1 shows a and b with the attack [b, a]; step 2 adds c and the attack [c, b]; step 3 adds d and the attack [d, c]. Extensions are recomputed at each step. If the step field is omitted for an argument, steps are assigned automatically based on the order in which the arguments appear in the ARGUMENTS list. Specifically, each argument is assigned to a new step in sequence.
Top and Bottom Layout
The top and bottom annotations control the vertical placement of arguments in the graph. Arguments marked top are positioned at the top of the layout, and those marked bottom at the bottom. The graph layout is computed using BFS distances from these root nodes.
ARGUMENTS:
a:
anchor: top
b:
c:
d:
anchor: bottom
e:
anchor: bottom
ATTACKS:
b: [a]
c: [b]
d: [c]
e: [b]
When no anchor is provided, the first argument defaults to the top root and the last argument defaults to the bottom root.
Development
- Install dependencies:
npm install
- Compile TypeScript:
npm run compile
- Export as the VSIX file:
npx vsce package
Release Notes
v0.1.1
- Decisions — pose yes/no questions about whether an argument appears in a given extension type, with answers updating at each step
- Cases — assign arguments to named cases and filter the graph by case; extensions are recomputed per step and per active case filter
- Simplified YAML format — argument fields (
summary, details, step, anchor, cases) are now direct keys under the argument ID instead of list items; top/bottom replaced by anchor: top/anchor: bottom; the attacks field is a mapping from attacker to targets (e.g. b: [a]) instead of a list of pairs
- Keyboard shortcut —
Ctrl+/ (or Cmd+/) to toggle comments on selected lines in the YAML editor
- Extension computation via afsolver — the hand-written semantics code is replaced by the afsolver npm package (same algorithms, now maintained as a standalone library)
- Argument labeling colors — clicking an extension labels every argument as in, out, or undec; both themes show each label with a distinct color (Green: dark green/light green/white; XRAY: blue/orange/yellow)
- Labelling legend & distinguish switch — a legend bar appears below the graph while an extension is selected; by default out and undec share a single "Not in" color, and the "Distinguish Out/Undec" checkbox switches to distinct out/undec colors
- Green theme updates — argument borders are now black instead of dark green (matching the XRAY theme)
- Case-insensitive field names — the top-level
EXHIBIT, ARGUMENTS, ATTACKS, and DECISIONS keys are matched regardless of case (exhibit, Attacks, etc. all work); examples and docs now use the uppercase form
cases: all wildcard — the scalar cases: all assigns an argument to every named case in the file; a list such as cases: [all] still denotes a literal case named "all"
v0.1.0 (2026-02-07)
Initial release with interactive report generation for a given argumentation framework.
v0.0.1 (2026-01-13)
Early version with Python dependencies (deprecated).
