1. The Question

Fusion power has 36+ competing approaches at various stages of maturity. How do you compare their economics?

Decision-makers — investors, policymakers, researchers — need structured comparisons, not just headline LCOE numbers. But comparing fusion economics across fundamentally different approaches is hard: different confinement mechanisms, different cost structures, different data quality, different estimation maturity.

This project builds the analytical infrastructure for that comparison: a taxonomy of the concept space, reusable cost modeling patterns, and traceable parameter chains from source literature to model outputs. The models are built in SysML v2 using agent-assisted tooling.

Research Questions

These five questions drive all downstream work — taxonomy, source selection, modeling targets, and comparison methodology.

Comparison Axes

Every concept model must produce outputs along these dimensions to enable apples-to-apples comparison.

Scope

2. The Scaffold

What structure enables all downstream work?

Bootstrap

A single command installs the full agent-assisted MBSE workflow into a project:

This gives Claude Code access to the full MBSE command set — research, spec, design, plan, implement, validate, and status tracking — plus skills for SysML conventions, requirements tracking, and model validation. User-owned files are never overwritten; tool-owned files auto-update when the toolchain updates.

Project Structure

Fusion TEA Initialization

Three governance documents are created at project setup. They define what we're investigating, what rules our models follow, and what structural decisions have been made.

3. The Workflow

How does work flow through the system, and where do artifacts land?

Traceability — The Cross-Cutting Concern

Every quantitative value in the system — from source documents through to model parameters — carries a structured citation chain. This is the mechanism that prevents hallucination and makes the analysis verifiable.

Each link is a file path that resolves within the repository. Citations use a standard format (Source / Ref / Basis) and scripts/trace_audit.py (planned) will walk these chains to report coverage gaps. Parameters without source data must be explicitly marked as assumed — silent invention is a rule violation (MR-4).

Visibility

A single command shows where everything stands:

This is the actual current output — sparse because modeling work hasn’t begun. As work items flow through the pipeline, the dashboard shows their stage (speccing, designing, implementing), validation status, and traceability coverage. State is derived from YAML frontmatter + filesystem scanning — no separate database.

5. Source Ingestion

Domain literature is ingested through a Zotero → extract → register pipeline, producing structured markdown that downstream research and modeling can cite directly.

Pipeline

The ingestion script searches our Zotero library by tag, downloads matching PDFs, extracts each to structured markdown, and registers the result in SOURCE_INDEX.md. A single command processes an entire batch:

Corpus

For this demo, we searched Zotero for papers on inertial fusion energy (IFE) economics and identified 5 that provide a breadth of data across driver technologies and time periods:

Extractions

Each paper is converted to structured markdown that preserves headings, tables, equations, and figure references. Here’s what that looks like — a 1986 scanned paper alongside its extracted markdown:

Original PDF (1986 scan)

Extracted markdown

## ECONOMIC STUDIES FOR HEAVY-ION-FUSION ELECTRIC POWER PLANTS

Wayne R. Meier, William J. Hogan, Roger O. Bangerter
Lawrence Livermore National Laboratory, Livermore, CA 94550

## ABSTRACT

We have conducted parametric economic studies for heavy-ion-
fusion electric power plants. We examined the effects on the cost
of electricity of several design parameters: cost and cost scaling
for the reactor, driver, and target factory; maximum achievable
chamber pulse rate; target gain; electric conversion efficiency; and
net electric power. Using the most recent estimates for the
heavy-ion-driver cost along with the Cascade reactor cost and
efficiency, we found that a 1.5 to 3 GWe heavy-ion-fusion power
plant, with a pulse rate of 5-10 Hz, can be competitive with
nuclear and coal power plants.

## INTRODUCTION

The Heavy-ion-fusion Systems Assessment Project has produced
new estimates of the capital cost and performance of an induction
linac accelerator for inertial fusion. …

And a clean modern extraction — the Xcimer laser cost table extracted perfectly from PDF to structured data:

Original PDF table

Extracted markdown table

| Laser Component | Cost/J |
|---|---|
| Laser Pump Source | |
|   Pulsed Energy Storage Capacitors | $10 |
|   Marx Generator | $24 |
|   Electron Beam components | $17 |
| Subtotal | $51 |
| Laser Gain Media, Optics, Other | |
|   Laser Chamber & Gas Systems | $19 |
|   Laser Output Windows & Optics | $12 |
|   Seed Lasers / NLO Systems | $23 |
|   Control, Diagnostics, Other | $4 |
| Subtotal | $58 |
| Total FOAK excimer-NLO | $109/J |
| DPSSL (aggressive est.) | $700–$1000/J |

Extraction quality varies with source age and format. Modern PDFs (2013+) extract cleanly. Older scanned documents (1986, 1992) produce usable text with some OCR artifacts — cosmetic noise on headers, occasional garbled characters — but the equations, cost data, and parametric relationships that matter for downstream research come through. Issues are documented honestly rather than hidden. See Appendix A for details.

Source Strategy

Rather than prescribing specific sources upfront, the project defines data layers needed at each depth level. Sources are selected to fill these layers as the investigation progresses.

6. Domain Research

Extracted sources are systematically researched against the investigation’s questions, producing structured domain insights (DI-XXX) that flow into modeling work. The /research command orchestrates this — an agent reads sources, synthesizes findings, and proposes insights for human approval.

The Research Session

We directed the agent to research IFE system economics for first-pass model structure, searching across all ingested sources. Here’s how that conversation unfolded:

8 sources were read in parallel. The agent synthesized findings into a structured report, proposed insight candidates, and — on approval — ran agentic-mbse pm approve-research to move the report from pending/ to approved/ and register DI-XXX entries in KNOWLEDGE.md. The human reviews each element separately: the report itself, then each insight candidate.

The Research Report

The approved research document lives at knowledge/research/approved/20260302-165055_ife-system-modeling-first-pass.md. Here’s how it’s structured — YAML frontmatter for machine-readable metadata, then sections with source citations throughout:

Every claim in the report cites its source with a tag like [Hawker-2020] or [EIF-1992], resolved at the bottom to specific file paths:

Registered Domain Insights

The research produced 5 domain insights — structured facts approved through the curation gate and registered in knowledge/KNOWLEDGE.md. These are the durable knowledge artifacts that downstream modeling work cites:

What Emerged: Modeling Target

The research revealed that no single IFE driver type has sufficient CAS-level data for a bottom-up model on its own. But Hawker’s 14-parameter framework provides a complete, technology-agnostic model that can be populated immediately — and then instantiated with driver-specific parameters.

This decision is captured as a durable intent document at modeling_project/intent/IFE Modeling Target Selection.md, bridging the research findings to the modeling epic that follows.

The Knowledge Transformation

Here’s what happened in this stage:

The pipeline: unstructured PDFs (Section 5) became structured extractions, which were researched against specific questions to produce a report with 7 detailed sections. From that report, 5 structured domain insights were extracted through human review. Those insights — plus the data gaps they revealed — drove the modeling target decision. Each step narrows and structures: 8 sources → 1 report → 5 insights → 1 decision.

7. Concept Modeling

Domain research (Section 6) produced a modeling target decision. This section follows the Stage 2 pipeline from Section 3 — Planning (turning that decision into tracked work items) and Execution (running each work item through the spec → design → plan → implement cycle).

Planning

Section 6 ended with a decision: build a generic IFE cost model using Hawker’s 14-parameter framework, then instantiate with Heavy Ion Beam parameters. That decision lives in an intent document (modeling_project/intent/IFE Modeling Target Selection.md). The first step is turning it into tracked work.

The /backlog add command reads the intent document, assesses the scale of work (this is an epic — multiple items with dependencies), decomposes it into individually deliverable work items, and registers everything through the CLI:

The agent read the intent document, identified three work items with a strictly sequential dependency chain (library → generic model → HIF instantiation), created an epic file with full context, and registered each item via agentic-mbse pm add-item. The YAML frontmatter in work/BACKLOG.md is the machine-readable source of truth; the rendered markdown table is derived from it.

With the epic registered, the dashboard shows the planned work — three items in the backlog, zero validations, nothing started yet:

Execution

Each work item runs through the same cycle: /spec-model → /design-model → /plan-model → /implement-model. At each stage, the agent produces a durable artifact that the next stage builds on — and the dashboard tracks progress throughout.

Three work items were executed in sequence. WI-006 (library patterns) gets the deepest showcase below — it’s the “from scratch” case. WI-007 and WI-008 follow the same cycle with progressively more reuse.

What a Spec Looks Like

The /spec-model command produces a requirements specification — what to build, traced to domain insights. Here’s the WI-006 spec, showing YAML frontmatter (machine-readable state) and the modeling requirements it derives:

Every spec requirement traces backward to either a domain insight (DI-XXX from Section 6) or a project modeling requirement (MR-X from REQUIREMENTS.md). This is what makes the pipeline verifiable: you can audit any model parameter back through spec → insight → source document → page number.

What a Design Looks Like

The /design-model command takes the spec and produces an architecture — which SysML elements to create, how they relate, and why. Here’s what the WI-006 design decided:

The design also includes a full prototyping phase — the agent writes SysML, runs it through the parser, fixes issues, and iterates until all files pass validation. By the time design is “complete,” the SysML already works:

models/library/
  foundation/
    economic_parameter.sysml    # attribute def + CAS Scope enum
    costed_component.sysml     # abstract part def (standard interface)
  cost_structure/
    cas_hierarchy.sysml         # 9 CAS level 2 part defs
    ife_cost_parameters.sysml   # 14 Hawker parameters with metadata
  analyses/
    ife_lcoe.sysml              # closed-form DCF calc def
    fusion_cycle.sysml          # recirculating power + viability constraint

What a Plan Looks Like

The /plan-model command takes the design and produces a phased execution plan with validation checkpoints. Since the design already includes a validated prototype, the plan focuses on refinement and integration:

Each plan phase has concrete checkboxes that get marked off during /implement-model. The plan is a durable artifact — if implementation spans multiple sessions, the next session reads the plan and resumes where the checkboxes stop.

The SysML Models

Here’s what the actual model code looks like. This excerpt from ife_cost_parameters.sysml shows how each of Hawker’s 14 parameters carries metadata and traceable citations:

And here’s how a concrete concept model specializes the library. The HIF driver derives its cost from Meier’s engineering formula, which then feeds automatically into the inherited Hawker LCOE calculation:

The key pattern: :>> cost_per_joule = meier_cost.gamma — the HIF driver’s cost is dynamically derived from Meier’s engineering formula (beam energy, efficiency, chamber count, rep rate), then automatically flows into the inherited Hawker LCOE calculation. One model element bridges two independent cost models from two different papers separated by 34 years.

Validation

Every SysML file is run through the parser. All 11 files across 3 work items pass:

Beyond parsing, each work item registers validation checks in the project’s VALIDATION_MATRIX.md. These range from structural checks (“are all required subsystems present?”) to reasonableness checks (“is the LCOE within the expected range?”):

Showing 5 of 15 total validations. The full matrix covers parse checks, structural completeness, dimensional consistency, parameter range reasonableness, and cross-validation against reference values from the source literature. All 15 pass.

Requirements Compliance

We defined 6 modeling requirements in REQUIREMENTS.md before any models were built. Did the pipeline follow its own rules?

Dashboard: After Completion

Compare this to the “before” dashboard above. Three work items completed, 15 validations passing, zero failing:

The dashboard is derived from YAML frontmatter and filesystem scanning — no manual state to maintain. Work item status, validation results, and completion dates are all tracked automatically. 6 architectural decisions (AD-001–006) were registered during modeling and now constrain future work.

The Knowledge Transformation

The full pipeline: domain insights and intent documents became a structured epic with 3 sequenced work items. Each work item produced spec → design → plan → SysML artifacts. The library (WI-006) established patterns, the generic model (WI-007) assembled them into a plant, and the HIF instantiation (WI-008) populated concrete values from source literature. Every quantitative value traces back to a specific page in a specific paper.

8. Visualization & Analysis

The models built through the workflow in Section 7 aren't just SysML files — they're machine-readable, introspectable artifacts. The extraction toolchain parses them via syside and produces structural views, while the calculation definitions encode the complete cost logic with traceable parameters. This section shows what the toolchain produces from the HIF/Osiris concept model.

Structural View

The extraction CLI walks the syside AST to build the containment hierarchy — which parts contain which sub-parts, with their type definitions. For the HIF plant, this shows the Osiris design decomposed into driver, target factory, and reaction chamber (with its CAS22 sub-accounts).

Calculation Data Flow

The HIF plant model encodes two independent cost calculation chains, both expressed as SysML calc def elements with formally declared inputs and outputs. Every parameter traces to a source subsystem and a literature citation.

The Hawker chain (blue edges) implements a general IFE LCOE model with 14 input parameters and 15 intermediate computations. The Meier chain (purple edges) uses HIF-specific parametric cost formulas from 1986 for independent cross-validation. Both chains share plant-level operating parameters but produce independent cost outputs — LCOE in $/MWh vs. COE in ¢/kWh (1988$).

Library vs. Design Architecture

The model is organized in three layers — each more concept-specific than the last. This separation is enforced by MR-3: library definitions must remain concept-agnostic so they can be reused across any fusion approach.

The pattern in action — the abstract IFE Driver declares what every inertial fusion driver must have. The concrete HIF Driver fills in how with values from source literature:

The abstract definition declares four interface attributes with no defaults — each driver type must provide its own values. The HIF driver adds beam-energy and Meier cost-formula attributes, then fills in the interface with Osiris reference values. A laser driver or pulsed-power driver would specialize the same interface with completely different values and cost models, but the LCOE calculation chain would work identically.

With one concept modeled (HIF/Osiris), the infrastructure is proven. Adding a second concept — laser IFE, pulsed-power, or magnetic fusion — means specializing the same generic template with different driver parameters and source literature. The comparison axes (LCOE, CAS breakdown, sensitivity profile) are already built into the model structure.

Appendix A: PDF Processing Details

Quality Gates

The extraction pipeline doesn’t blindly convert PDFs to markdown. Each page passes through a quality gate that compares base extraction against ensemble table detectors (GMFT, Img2Table). When the gate detects missed tables or structural issues, it routes the page to Claude for enhanced extraction.

Example from the Xcimer laser fusion paper (28 pages):

Only 4 of 28 pages needed Claude enhancement — all triggered by tables that the base extractor missed but GMFT detected. This selective approach keeps costs down while ensuring critical data (like the FOAK laser cost breakdown at $109/J) is captured correctly.

Per-Paper Extraction Quality