Test Systems

Reviewing AI suggestions

When the dev panel finds a missing or invalid case-meta field, you can ask GridArena to draft a fix. The suggestion flow is read-only by default — nothing is written to the merged CASE_META until you explicitly accept it — and every accept or revert is recorded in an append-only audit trail (see the validation feedback loop for the end-to-end picture).

1. Open the suggestion drawer

Click Suggest fix on any issue row. The right-hand drawer calls suggestCaseMetaFix, which sends the case key, field, and current value to the configured LLM and returns a structured proposal: the new value, the model that produced it, and a short rationale. A spinner appears while the request is in flight; failures show an inline toast and leave the panel unchanged.

2. Inspect the diff

The drawer renders the previous value next to the proposed value so you can eyeball the change before committing. Use this to catch hallucinated source_url values, wrong last_reviewed dates, or rationales that don't match the field type. If the suggestion is wrong, just close the drawer — nothing is persisted.

3. Accept or revert

Accept writes a row to case_meta_overrides and immediately re-merges the override into CASE_META so the validator re-runs. Accepted overrides appear in the Overrides table directly under the dev panel. Each row has a Revert action that deletes the override and restores the original value — the UI updates optimistically and rolls back if the server rejects the request.

4. Bulk actions

For sweeps across many cases, tick the row checkboxes in the Overrides table and use Bulk revert to remove a batch in a single database round-trip. The audit trail records one entry per affected override so the history stays granular even when the action was bulk.

5. Audit trail

Every accept and revert is appended to case_meta_override_audit with the actor, timestamp, action, previous value, new value, and the AI model + rationale (when the action originated from a suggestion). The Audit history panel below the Overrides table renders the chronological log so you can answer "who changed this field, when, and why" long after the fact. Audit rows are user-scoped via RLS and cannot be edited or deleted.

Exporting invalid items

The dev panel above lists every case-meta validation issue detected at build time. Two scope-aware dropdowns at the top of the panel — Export CSV and Export JSON — let you download the currently filtered list of invalid items for offline review or for attaching to a bug report.

Filter and sort awareness

Exports follow the panel's active filter and the on-screen sort order exactly. A display_order column is included in every row so you can trace any line in the export back to its position in the panel, even after re-sorting or re-filtering.

Choosing a scope

Each dropdown offers three scopes. Counts shown next to each option are live, and an option is disabled when its bucket is empty:

• All — every issue in the current filter.
• Errors only — rows where a required field is missing.
• Warnings only — rows where a field is present but its format is invalid.

The severity column reflects this distinction: error for missing fields, warning for invalid formats.

Preview before download

Choosing a scope opens a preview modal instead of downloading immediately:

• CSV preview — a table of up to the first 50 rows showing case_key, severity, field, and message, plus the total row count and the active filter.
• JSON preview — the full payload rendered in a code block so you can inspect the exact structure before saving.

Both modals expose Download and Cancel buttons, and Esc dismisses the preview without downloading.

CSV column schema

JSON shape

The JSON export mirrors the CSV: an array of objects with the same six keys per row, in the same order as the on-screen list.

Worked examples

CSV:

display_order,case_key,severity,problem_type,field,message
1,case14,error,missing,prompt_version,
2,case14,warning,invalid,random_seed,"random_seed must be an integer"

JSON:

[
  { "display_order": 1, "case_key": "case14", "severity": "error",
    "problem_type": "missing", "field": "prompt_version", "message": "" },
  { "display_order": 2, "case_key": "case14", "severity": "warning",
    "problem_type": "invalid", "field": "random_seed",
    "message": "random_seed must be an integer" }
]

GridArena ships three built-in IEEE-style transmission benchmarks — case5, case14, and case30. They are simplified, deterministic versions of well-known reference networks, embedded directly in the codebase (src/server/simulation/cases.ts) so the in-Worker DC power flow and the optional PyPSA microservice produce reproducible results without external downloads.

The tables below are generated at build time from the actual case definitions, so what you see here is exactly what the solver runs.

Engine assumptions

Both solvers use DC power flow:

• Lossless network (line resistance ignored).
• Flat 1.0 pu voltage magnitudes — voltage-magnitude violations are always empty.
• Small-angle approximation (sin θ ≈ θ).
• Generator dispatch is greedy merit-order by marginal cost to cover total load before each PF run.

These assumptions make results meaningful for line loading, thermal violations, and redispatch, but not for reactive power, voltage collapse, or losses.

Supported actions

The solvers accept these structured actions on any case:

• scale_all_loads — multiply every load by value.
• set_generator_p_mw — set generator at target_index to value MW.
• line_outage — remove branch at target_index.
• shed_load — shed value MW total, scaled across loads.

Supported perturbations

For sensitivity / robustness analysis (batch perturbation jobs):

• load_scale / load_increase — scale every load by parameter_value.
• line_rating_decrease — scale every line s_nom by parameter_value.
• generator_outage — remove generator at index parameter_value.

References

• MATPOWER — canonical .m case archive (case5.m, case14.m, case30.m).
• PyPSA documentation — engine used by the optional simulation microservice.
• Illinois Center for a Smarter Electric Grid — one-line diagrams and history of the IEEE 14 / 30 systems.
• In-repo: src/server/simulation/cases.ts, src/server/simulation/dc-powerflow.ts, simulation-service/README.md.