Polish copy and UI labels for demo

docs/DEMO_SCRIPT.md

@@ -1,13 +1,45 @@
-# Demo Script (Draft)
-
-Lightning mode is built for the infra engineer standing up 1.3-GW-class AI campuses. With a single preset, it simulates a
-network change in our MAESTRO lab, runs targeted pre- and post-change checks, and returns a risk score and explanation in
-a few seconds via MCP and the Hugging Face Space UI. MCP provides the standardized interface for tools and agents,
-MAESTRO supplies the realistic multi-vendor lab, and the Space gives judges and operators a one-click way to see risk
-before they ever touch production.
-
-1. Open the Gradio Lightning UI (`python space/app.py`).
-2. Choose a change type and scenario (e.g. "TOR uplink shutdown"). Mention to the audience what change you selected and why it matters.
-3. Click "Run Lightning Simulation".
-4. Call out the returned `risk_score` and `risk_level`; explain how they align with the scenario you just chose.
-5. Highlight one or two bullets from the pre/post checks plus the blast radius summary and explanation so the judges see why Lightning made that decision.
+## Persona & setup (10–15s)
+
+“You’re an infra engineer bringing up a new AI data-center: hundreds of racks, ToR switches, and a spine–leaf fabric. You can’t afford to guess how risky each change is. This MCP server simulates those changes in our MAESTRO lab and gives you a risk score before you touch production.”
+
+## Demo flow (60–90s)
+
+1. **Open the Space / name the pieces (5–10s)**  
+   - Show the HF Space.  
+   - Say: “This Hugging Face Space is just the front-end. Underneath is an MCP server talking to our MAESTRO lab—a GNS3 fabric plus Ansible, Nornir, and pyATS for checks.”
+
+2. **Scenario 1 – Low-risk VLAN staging (20–25s)**  
+   - In the UI:
+     - Change type: VLAN
+     - Scenario: Stage VLAN on leaf pair (preset `leaf_tor_vlan_stage`)
+     - Click **Run Lightning simulation**.  
+   - Narrate: “First scenario: staging a VLAN on a pair of leaf switches—no traffic swing yet. Lightning mode looks at MAESTRO’s health, the size of the change, and our expected blast radius, and gives us a risk score and explanation.”  
+   - Point to:
+     - Low risk score (~14).
+     - Pre-checks: fabric healthy, no existing alarms.
+     - Post-checks: staged VLAN present, no new issues.  
+   - One line: “On a healthy fabric, small, localized changes show up as low-risk with blast radius limited to a couple of leafs.”
+
+3. **Scenario 2 – Riskier TOR uplink shutdown (25–30s)**  
+   - Change type: Interface  
+   - Scenario: Shutdown TOR uplink in redundant pair (preset `tor_uplink_shutdown`)  
+   - Click **Run Lightning simulation**.  
+   - Narrate: “Now a riskier scenario: shutting down one TOR uplink in a redundant pair. Same MCP call, same lab, but the risk model knows this can break redundancy.”  
+   - Point to:
+     - Medium risk score (~50–60).
+     - Pre-checks: MAESTRO health OK.
+     - Post-checks: one adjacency lost, new alarm on the TOR; blast radius confined to one rack.  
+   - One line: “Even though traffic stays up, the risk score jumps, and the explanation tells us exactly why: lost redundancy and new alarms.”
+
+4. **Scenario 3 – BGP fabric neighbor add (20–25s)**  
+   - Change type: BGP neighbor  
+   - Scenario: Add fabric neighbor on leaf (preset `leaf_bgp_fabric_neighbor_add`)  
+   - Click **Run Lightning simulation**.  
+   - Narrate: “Finally, a control-plane change: adding a BGP fabric neighbor on a leaf. We treat BGP changes as inherently more sensitive, even when they succeed.”  
+   - Point to:
+     - Medium-ish risk (~37).
+     - Checks: MAESTRO health OK, new neighbor established, no lost adjacencies.  
+   - One line: “Control-plane changes start at a higher risk baseline, but you still get a quick pass/fail signal from the lab in a single MCP call.”
+
+5. **Closing (10–15s)**  
+   - Narrate: “From an agent’s perspective, this is just one MCP tool—`simulate_network_change`—that returns risk, blast radius, and explanation in seconds. From a human’s perspective, it’s a way to de-risk common changes in a 1.3-GW data-center rollout without ever hitting production.”

docs/README.md

@@ -1,5 +1,18 @@
 # Network Change Simulator (NCS)
 
+**Network Change Simulator (NCS)** is an MCP server and Hugging Face Space that lets an infra engineer safely trial network changes *before* touching production. It simulates VLAN / interface / BGP neighbor changes against a real MAESTRO lab (GNS3 + Ansible/Nornir/pyATS), runs targeted pre- and post-change health checks, and returns a 0–100 risk score with an explanation in a few seconds. Lightning mode gives a fast, MCP-driven risk assessment for common change presets; the full mode is reserved for deeper, slower validation later.
+
+## Why this exists
+
+**Who it’s for**  
+Infra and SRE engineers standing up or expanding AI/data-center campuses—hundreds of racks, ToR switches, and spine–leaf fabrics—who need to know “how risky is this change?” *before* they push configs.
+
+**What Lightning does**  
+Lightning mode takes a change preset (VLAN, TOR uplink, BGP neighbor), queries MAESTRO’s health, combines that with the change magnitude, and returns a risk score (0–100) plus pre-/post-check summaries and blast radius text—all via a single MCP tool and a one-page Space UI.
+
+**Why MCP + MAESTRO + HF Space**  
+MCP gives agents and tools a standardized way to request simulations and read risk, MAESTRO provides a realistic multi-vendor lab underneath, and the Hugging Face Space gives judges and operators a one-click way to see risk in seconds without touching production gear.
+
 Lightning mode is built for the infra engineer standing up 1.3-GW-class AI campuses. With a single preset, it simulates a
 network change in our MAESTRO lab, runs targeted pre- and post-change checks, and returns a risk score and explanation in
 a few seconds via MCP and the Hugging Face Space UI. MCP provides the standardized interface for tools and agents,

docs/VIDEO_SCRIPT.md

@@ -0,0 +1,13 @@
+# NCS Video Script (Draft)
+
+## Hook (10–15s)
+“Modern AI data-centers are huge: hundreds of racks, thousands of ToR ports, and tight maintenance windows. One bad config push can take down an entire fabric. This project turns network changes into an MCP call that simulates the change in a lab and gives you a risk score in seconds—before you ever touch production.”
+
+## Problem (30–40s)
+“Imagine you’re the engineer responsible for standing up a 1.3-GW AI campus. Every maintenance window juggles VLAN adds, TOR uplink toggles, and BGP fabric updates. You need to know, fast, whether a change threatens core BGP, affects two racks or twenty, and whether MAESTRO (our lab) is already unhappy. Today you guess or build custom playbooks; tomorrow an MCP tool does it for you.”
+
+## Solution / Demo (30–40s)
+“Network Change Simulator is an MCP server plus this Hugging Face Space. Lightning mode takes a preset, runs MAESTRO health, simulates the change, and returns risk, pre/post checks, and blast radius. VLAN staging stays low risk, TOR shutdowns spike into medium, BGP neighbor adds sit midrange even when all checks pass. It’s a single MCP call whether you’re a human or an agent.”
+
+## Closing (10–15s)
+“Lightning mode is live today: one MCP tool, a handful of presets, and a real MAESTRO lab under the hood. Full mode will tackle slower, deeper validation, but the shape remains the same—MAESTRO for realism, MCP as the glue, Spaces for a one-click risk readout before you touch production.”

space/app.py

@@ -11,11 +11,11 @@ PRESETS = {
     },
     "Interface": {
         "Enable TOR uplink": "tor_uplink_enable",
-        "Disable TOR uplink": "tor_uplink_shutdown",
+        "Shutdown TOR uplink": "tor_uplink_shutdown",
     },
-    "BGP Neighbor": {
-        "Add fabric neighbor": "leaf_bgp_fabric_neighbor_add",
-        "Remove fabric neighbor": "leaf_bgp_fabric_neighbor_remove",
+    "BGP neighbor": {
+        "Add fabric neighbor on leaf": "leaf_bgp_fabric_neighbor_add",
+        "Remove fabric neighbor on leaf": "leaf_bgp_fabric_neighbor_remove",
     },
 }
 API_URL = os.getenv("NCS_SERVER_URL", "http://localhost:8000/mcp/simulate")
@@ -48,9 +48,9 @@ def run_sim(change_type_label: str, scenario_label: str):
 
 
 with gr.Blocks(title="Network Change Simulator") as demo:
-    gr.Markdown("# Network Change Simulator (Lightning Stub)")
+    gr.Markdown("# Network Change Simulator (Lightning mode)")
     with gr.Row():
-        change_type = gr.Dropdown(choices=list(PRESETS.keys()), label="Change Type", value="VLAN")
+        change_type = gr.Dropdown(choices=list(PRESETS.keys()), label="Change type", value="VLAN")
         scenario = gr.Dropdown(choices=list(PRESETS["VLAN"].keys()), label="Scenario")
 
     def update_scenarios(ct):
@@ -58,14 +58,16 @@ with gr.Blocks(title="Network Change Simulator") as demo:
 
     change_type.change(update_scenarios, inputs=change_type, outputs=scenario)
 
-    run_btn = gr.Button("Run Lightning Simulation")
+    run_btn = gr.Button("Run Lightning simulation")
+    gr.Markdown("*Simulated in MAESTRO lab – no production impact.*")
 
-    risk_score = gr.Number(label="Risk Score")
-    risk_level = gr.Textbox(label="Risk Level")
-    pre_checks = gr.Markdown(label="Pre-check Summary")
-    post_checks = gr.Markdown(label="Post-check Summary")
-    blast_radius = gr.Textbox(label="Blast Radius Summary")
+    risk_score = gr.Number(label="Risk score (0–100)")
+    risk_level = gr.Textbox(label="Risk level")
+    pre_checks = gr.Markdown(label="Pre-change checks")
+    post_checks = gr.Markdown(label="Post-change checks")
+    blast_radius = gr.Textbox(label="Blast radius")
     explanation = gr.Textbox(label="Explanation")
+    gr.Markdown("**MCP Lightning: risk in seconds before you touch production.**")
 
     run_btn.click(
         run_sim,