Rivian Run Sheet

Task 1: 20-minute first sales call. Audience: Rivian Head of Systems Engineering evaluating purchase. Goal: close on next steps, not a feature tour.

Before the call: 15-min setup

Day-before email (send it)

“Looking forward to tomorrow. Here's what I'm planning to cover: [2-3 sentence overview]. Is there anything specific you'd want to make sure we get to so we can make this as relevant as possible?”

Surfaces surprises before you're live. Shows you're consultative. Any answer they give becomes a “you mentioned...” in the opening.

Screen share demo. Four browser tabs pre-opened so every beat snaps instantly. The sandbox project is a temperature/humidity test chamber called TestEquity 123H.

Tab 1Beats 1-2Requirements, Tree mode, TestEquity 123H root expanded

→Go to app.flowengineering.com, candidate-2 org, candidate-2-demo-project
→Left sidebar: Requirements
→Switch view to Tree at the top of the panel
→Expand root: TestEquity 123H, then Chamber Enclosure, Control & Sensors, Humidity Control (Cooling + Heating as children)

Tab 2Beat 3Analysis page

→Left sidebar: Analysis
→Click each model once to pre-load: Heating Model (Python/GitHub), Cooling Model, Reliability Model, Main Chamber Volume (Onshape)
→Leave parked on Heating Model

Tab 3Beat 4Testing page

→Left sidebar: Testing
→Click into Full Verification Test
→Confirm 'Automated Run — PASS' in the Last Run column for Humidity Accuracy and Temperature Uniformity (shows as 'Automat...' truncated)
→Confirm the Iterations dropdown is visible at the top without scrolling

Tab 4Beat 5 (live refresh)Requirements, Cooling Subsystem, Table mode

→Duplicate Tab 1
→Click into Cooling Subsystem node, switch to Table mode
→REQ-35 (power budget) lives here. Claude updates it from 1950 W to 2150 W during Beat 5b
→Refresh this tab live so the audience sees the number flip

Claude Code — right 40% of screen

Open Claude Code with projects/cowork-flow-interview/ as root — this loads the flow-demo MCP automatically. Type “what flow tools do you have?” and confirm 10 flow_* tools appear. Flow UI left 60%, Claude Code right 40% — both visible at once.

Five REQ IDs to know cold

REQ-28 — Does the chamber hold the temperature you set? It has a red X (verification failed) visible in the table. Inherited by Cooling from the root — the subsystem didn't write it, it arrived automatically. You say its name in Beat 2 and call out the failure in the close.
REQ-34 — Are all corners of the workspace the same temperature? Also inherited by Cooling. Travel with REQ-28 as your two "inherited constraint" examples in Beat 2.
REQ-35 — How much power does the whole system draw from the wall? Currently 1950 W. You raise it to 2150 W live in Beat 5. Know both numbers cold — if you hesitate during the live write, the moment falls flat.
REQ-37 — How long should the humidity sensor last before it fails? This is the row you click in Beat 2 to show the side panel: statement, value, owner, stage, all in one record. Know which row it is before you're on screen share.
REQ-39 — Will the whole system last long enough in the field? Target is 20,000 hours, the Reliability Model says we're at 54,000 — nearly 3x over. Stage is Released (the only Released req in the table — visually distinctive). Beat 5 has Claude reason about this margin.

Branch on their answer

Lead with what's working (Ted's rule). Once they've described their setup, branch immediately. The whole demo shifts shape based on which path you're on.

“Tell me about how your team manages requirements today. What parts of that are actually working well for you?”

A"We use DOORS" (or Jama)

"I get it, 20 years of pipelines don't change overnight. What we typically see is teams bring Flow in alongside DOORS for their highest-value areas first. Get their feet under them, run faster V-cycles on the active work. Over time they have the option to migrate if they choose. The import tooling round-trips DOORS reqifs so nothing gets thrown away."

Lean on

→ Beat 1 — Report view
→ Beat 2 — flow-down
→ Beat 3 — design values

Never say 'rip and replace'. Complementary first, migration optional.

B"Spreadsheets / Confluence"

"Right now you have a Status column someone manually updates. With Flow, it updates when the test passes. The spec regenerates every time you open the page. Nobody maintains it."

Lean on

→ Beat 3 — continuous verification for hardware
→ Beat 4 — verification dashboard

Beat 5 if they light up

C"Tool exists but nobody uses it"

"The reason engineers don't update it is that updating costs more time than the information is worth. When Claude reads and writes requirements on their behalf, the adoption problem inverts. The tool becomes valuable because the effort disappears."

Lean on

→ Beat 5 — AI demo first
→ Governance talking point

Frame Flow AI as the adoption engine

Demo Run Sheet — Rivian (20 min)

Sales Feed principles throughout: outcome framing before screen share, aha-moment management, silence as a tool, constant check-ins, flat-reaction recovery, name their next step before they do.

Interviewer context

Task 1: new prospect sales call. You are pitching Flow to Rivian as if they have never bought it. The interviewer plays Rivian Head of Systems Engineering evaluating whether to purchase. Background context (do NOT say in the demo): Rivian is actually a real Flow customer with 1,500 engineers on the platform — so the persona will be knowledgeable and realistic, not a blank slate. That makes this harder, not easier. Do not reference Rivian as a customer story; use Joby or Astranis instead. See /prep for full attendee bios.

Opening: Discovery first (2 min, no screen share)

Lead positive. Ask what's working well before asking what's broken — it disarms them and gets them talking. Then anchor on negative consequences, not just pain. Their exact words become your “you said...” ammunition during every beat.

Before you jump in — ask this first

“Where would you like to start in this demo?”

Gives them control. Shows you're consultative, not scripted. Some people say “just show me the dashboard” — adapt. Most will defer to you, which opens the discovery below.

1.“Tell me about how your team manages requirements today — what parts of that process are actually working well for you?”

Lead positive. Let them say what they like. Then follow up: "What's most important to you in how that works?" Their answer tells you what to anchor every beat on. If they light up about automation, lean Beat 3. If governance, lean Beat 5. If visibility, Beat 1.

2.“In your role you probably evaluate software tools fairly often — what do you typically look for when you're deciding whether something is worth your team's time?”

Positions them as an expert evaluator, not a mark. Their answer tells you what they value (automation, governance, UI, control). Revert to it during the demo: "You mentioned X earlier — this is exactly that."

3.“When a requirement changes at the system level — say a cell chemistry update — how does that reach the engineer designing to it today, and how long does it take?”

Beat 2 setup. Whatever number they give is the gap Flow closes. If they say it works fine, ask what the negative consequence would be if it slipped — that's the real pain.

Lead the witness — use this bridge

“Based on what you just said — [repeat their exact words] — that's exactly what I want to show you. 20 minutes, focused on that. Not a feature tour.”

Then during every beat: “Remember when you mentioned [X] — this is that.” Reference their words, not yours. That's what makes it feel tailored.

They agree. Now share your screen.

The 5 Beats

Beat 1 (3 min)Tab 1The living spec

Tab open:Requirements view — Tree mode, TestEquity 123H root expanded

What this view is	Same data, four views: Tree (hierarchy), Table (flat list), Report (numbered spec doc), Design Reviews (gate ceremonies) Tree mode: each node is a subsystem, each subsystem holds the requirements scoping what it must do The view-mode switcher at the top is the most important control on this page — know it cold
What it does	Replaces Word/Confluence + DOORS/Jira with one place The numbered spec doc and the live database are the same data Each node shows a rolled-up requirement count — see which subsystems are heavy at a glance
Why this beat is here	Core thesis: the spec isn't dead, it just stopped being the source of truth. If the interviewer doesn't accept requirements as a living artifact, nothing else in the demo lands.

Beat 2 (4 min)Tab 4Requirements flow down

Tab open:Requirements → Cooling Subsystem, Table mode

What this view is	Table mode = what a domain engineer opens day-to-day: flat list, their subsystem only, values visible without clicking REQ-35 and REQ-28 appear here because the SE scoped them to Cooling — the Cooling lead didn't write them or go find them Click the expand arrow on REQ-28 to show REQ-34 as a child (decomposed) requirement underneath it
What it does	No manual assembly — the Cooling lead's list is always current Change REQ-28 at the root → every subsystem it's scoped to updates Click any requirement → side panel: value, verification status, owner, stage, CR history (one record)
Why this beat is here	Closes Beat 1. Beat 1 = spec is alive. Beat 2 = propagation in practice.The phrase to land: “trace-by-default, not trace-by-audit.” For Rivian: a cell chemistry change reaches the pack thermal lead automatically, not via email.

Beat 3 (6 min)Tab 2Continuous verification for hardware (the money shot)

Tab open:Analysis page

What this view is	Each model card = one analysis job (Heating Model = one Python script, Reliability Model = another, Onshape = the 3D design file) Click into a card and you see the Model Values panel: the parameters the script reads (inputs you can tune) and the numbers it produces (outputs). Those outputs are what Flow captures as live Design Values and checks against requirements automatically None of this lives inside Flow — each card is just a pointer to a file elsewhere (GitHub, Onshape, Excel, MATLAB)
What it does	Python model runs → output becomes a Design Value → requirements know if they pass or fail automatically Bump a param in Onshape, re-sync → Flow pulls the new mass. No export, no manual entry. Verification becomes a continuous side-effect of designing, not a quarterly campaign
Why this beat is here	Where most demos either land the aha or lose the room. The insight: your existing tools become the verification engine, no rip-and-replace. Rivian's engineers already run automated simulations as part of development. Flow connects those outputs to the requirements record — so you always know which specs are satisfied without anyone manually updating a tracker.

Beat 4 (3 min)Tab 3Continuous verification and baselines

Tab open:Testing → Test Plans tab → Full Verification Test

What this view is	Navigate to Testing in the left nav, then switch to the Test Plans tab (not Systems). Systems organizes tests by hardware subsystem — one subsystem at a time. Test Plans organizes them by test campaign and shows all tests together. You need the full mix visible for this beat. Click into Full Verification Test to see the four test cases: two PASS (automated), two PENDING (physical). That contrast is the whole point. One row per test — any kind of test. "Automated Run PASS" = a script ran it, no one clicked anything. "PENDING" = a physical test that still needs someone to run the actual hardware. Flow doesn't care: Python script, someone running the physical chamber, a tech with a multimeter — same ledger. The Iterations dropdown is a time machine. On the day of each design review, Flow takes a snapshot — every requirement, every test result, every number — and saves it with a name. Click "CoDR Entry" and the page shows exactly what the project looked like on Dec 10. Click "Current" to come back. One click each way.
What it does	VP asks: "Is this what we approved at the design review?"— normally a 3-day dig through emails and old docs. Now it's a dropdown click. Before a gate review, teams usually spend days assembling test results into a presentation. With Flow, the project state IS the evidence — nothing to compile. Every test that runs automatically contributes to the picture. The team didn't do extra work — they just ran their tests.
Why this beat is here	The aha: audit prep stops being a task.For Rivian, Design Freeze Reviews need sign-off from 12+ teams. Each team currently pulls their own evidence package. With named baselines, there's nothing to pull — it's already there.

Beat 5: The AI moment (3 min, the payoff)

Split screen. Flow on the left, Claude Code on the right. Each prompt below tells you exactly which view to have open. The audience watches Flow update live after each prompt.

Frame it in Pari's thesis first

"Pari published the AI Systems Engineering Handbook two weeks ago. His thesis: AI reduces design time 10x, creates 10x more artifacts, creates 100x the alignment problem. Solution isn't smarter AI — it's structured requirements data AI agents can reason over. What you just saw in the last 15 minutes is what makes the next 3 minutes possible. This is Agentic Systems Engineering in practice."

Prompt 5a: read and reason (45 sec)

Flow view:Flow view: doesn't matter — nothing changes on screen. Stay wherever you are. The aha is watching the AI reason in the chat, not a UI update.

REQ-39 requires system R90/C90 (reliability stat: 90% of units still running after X hours) >= 20,000 hrs. What's our current margin, and which component MTBF (mean time before failure, i.e. how long before a component breaks on average) is the biggest risk if it degrades 20%?

Paste this into Claude Code on the right side of the screen.

Prompt 5b: propose and govern (90 sec — the money moment)

Flow view:Flow: Requirements → Heating Subsystem → Table. Find REQ-35 (Power Consumption) — it shows 1950 W. After you approve in the chat and hit refresh: REQ-35 jumps to 2150 W. Stage column still says Draft.

REQ-35 caps total power at 2500 W and we're at 1950 W. I want 200 W more heating headroom. Propose a new value for REQ-35, explain the tradeoff against REQ-33 and REQ-28, and if I approve, update the value and move the requirement to In Review. Keep the proposal to 5 bullets and then the two actions.

Paste this into Claude Code on the right side of the screen.

Prompt 5c: close the loop (45 sec)

Flow view:Flow: stay on Requirements → Heating Subsystem → Table. Find REQ-26 (Temperature Range High) — value shows 200. Run the prompt, then hit refresh. REQ-26 jumps to 225. Stage stays Draft (second CR opened).

The heating model shows REQ-26 (max workspace temp, target >= 200C) is achieving 233.3C — 33 degrees of margin. Tighten the spec to reflect what we actually build: update REQ-26 target to >= 225C and advance it to In Review.

Paste this into Claude Code on the right side of the screen.

Close: name the next steps for them (90 sec)

"You watched me do a tradeoff analysis and propose a requirement change in 90 seconds. Run ten of those a day, you run more full design-test-confirm cycles before R2 freeze."
"When REQ-35 changed, Claude flagged that REQ-28 is already FAILED. That's a pack-to-vehicle integration surprise caught in V1, not V3."
"Named baselines, change-request trail, agent-authored proposals. One dashboard, one question answerable in one click."

Then close like this

“Here's what I've seen happen at this point. Your team needs to go discuss internally. You've probably got questions to take back to colleagues who weren't on this call. So let me stop here and ask directly: what did you see today that was most relevant to where you are? And what would need to be true for this to be worth a deeper conversation?”

Stop talking. Wait for them.

Propose the reverse demo as next step

“What we did today was focused on your process and showed you our solution. As a next step, I'd love to flip it — get a reverse demo of your current setup and the tools you're actually using. Then we can come back and show exactly where we add value in your specific workflow, not a generic demo.”

Reverse demo = them showing you their process. It gives you a real storyboard and shows you're consultative, not closing. This is the next step that impresses.

Meta connection: why this prep IS the demonstration

Pari's thesis says you need structured requirements data for AI agents to work. My cowork monorepo is the same idea applied to knowledge work — a structured, context-rich research system where Flow's handbook is ingested, the sandbox is reverse-engineered into a walkthrough, decisions are version-controlled, and AI agents reasoned over that structure to write the MCP server, the script, and the slides. I didn't build a custom model. I built the data structure. That's exactly what Flow does for hardware teams. When this comes up in the demo, it's not an analogy — it's proof I think in the same paradigm Pari is staking the company on.

If the reaction is flat at any point

“I want to make sure I'm showing you the right things. What I just showed, does that map to a problem you actually have, or am I off base?”
“You seem like you're thinking about something. What is it?”
“Normally at this point people have one of two reactions. Either this is exactly what they've been looking for, or it's not the right fit at this stage. Which is it for you?”

Objections cheat sheet

Objection	Pivot
We already use DOORS / Jama	Flow can import DOORS requirement files (DOORS is a legacy requirements tool many defense/auto teams use). The question isn't rip-and-replace — it's 'do my next ten design-test cycles run faster here.'
Our scripts are proprietary	They stay in your GitHub. Flow reads outputs via your runners. Nothing leaves your network.
How do I get mechanical engineers to actually use it?	Their 3D design tool stays primary — Flow reads parameters on commit. They touch Flow at review, not mid-design. (Full Task 2 answer if they push.)
Pricing	Token-based pricing shift is mid-flight. Trial is flat monthly. Long-term quote once we see real load.
ISO 26262 (automotive safety standard) / DO-178C (aviation software standard) / AS9100 (aerospace quality standard) compliance	Handbook Vol 2 Ch. 8 covers iterative certification. Flow stores the trace chain. Iterations = signed baselines per gate. The evidence is a side-effect of development, not a quarterly assembly.
Did you write this MCP with an LLM?	Yes — paired with Claude Code on the scaffold, then hardened against the live sandbox. About a day. Any FDE I'd hire should work this way.
What if AI changes something without approval?	The Flow API returns 200 whether a stage transition went through or opened a CR. I caught this reading back every write — the API silently gates everything through governance even if the client assumes otherwise. That's the right failure mode.

End with the artifact

flow.thedefrag.ai

“What I built for this conversation is live at flow.thedefrag.ai. The MCP source, the Claude Code plugin, the Rivian and Anduril prospect pages — all there. That's what I'd hand a prospect at the end of an FDE engagement: a working integration they can pull and run against their own project, not a slide deck.”

If they ask “what would you do first as a deployment engineer (FDE)?” — “Harden the AI-to-Flow bridge (the MCP server) into a reference server your customers fork in a weekend. Expose change-requests and approvals as first-class tools so the agent can walk the full governance cycle. Per-user OAuth so the audit trail attributes to the engineer, not a service account.”