Demo Script

The compatibility story. DOORS users know the pain — static exports, broken traceability after changes, no live link between spec and design artifacts. Don't bash DOORS; acknowledge it.

“DOORS is a document tool pretending to be a system. It captures requirements well but it doesn't know what's verifying them. What you get with Flow is the same requirement living in the same record as its test results and its design values. The spec and the verification evidence are the same data, two views.”

Lean on: Beat 1 (Report view), Beat 2 (flow-down), Beat 3 (design values). Skip Beat 5 unless they ask.

The verification-status story. Lead with the dashboard.

“Right now you have a column called ‘Status’ that someone manually updates. The question I get from every SE team is ‘how do I actually know that column is right?’ With Flow, the status column updates when the test passes. The spec doc regenerates every time you open the page. Nobody maintains it.”

Lean on: Beat 3 (CI/CD for hardware), Beat 4 (verification dashboard). Beat 5 if they light up.

The adoption and AI story. Tool exists, nobody updates it. The MCP is the answer.

“The reason engineers don't update the requirements tool is that updating it costs more time than the information is worth to them. When Claude can read and write the requirements on their behalf — they describe what they changed, the agent does the update — the adoption problem inverts. The tool becomes valuable because the effort disappears.”

Lean on: Beat 5 (AI demo), the governance talking point. Frame Flow AI as the adoption engine.

Open Requirements view. Show the system tree hierarchy. Flip to Report view — the numbered document with ownership and IDs.

"This is the document your VP would sign. It regenerates every time you open the page. Nobody maintains it by hand."

Click into Cooling Subsystem. Show REQ-35 inherited from the parent chamber.

"The subsystem lead didn't pick which constraints to honor. They inherit automatically. When the Head of SE changes REQ-28, every subsystem's view updates."

The money shot. Show the Compressor Capacity design value (2200 W actual vs 1950 W required). The value came from an analysis model — Claude ran it. Point to the analysis model node in the tree.

"This is the CI/CD loop for hardware. The requirement defines the target. The analysis model computes the actual. The gap is always visible, never buried in a folder."

Switch to the testing view. Show which requirements have passing test runs.

"This is the answer to 'is it verified.' It's not a spreadsheet someone updated on Friday. It's the test results."

Prompt Claude live: "REQ-35 thermal power budget — raise the target to 2150 W and move it to In Review." Claude calls flow_update_requirement_value (value flips in the UI) then flow_update_requirement_stage (stage does NOT flip — a Change Request opens instead).

"Watch what just happened. The value updated directly because that's a data write. But when Claude tried to move the stage, Flow's governance intercepted it and opened a Change Request. The stage stays Draft until a reviewer approves it. AI as a tireless proposer, not an unchecked actor. The CR is the audit trail."