Anduril Activation Plan

Task 2: 15-minute domain engineer activation. Existing customer. 20 SEs active, domain engineers treating Flow as extra admin work. Goal: behavior change, not purchase decision.

Before the call: 15-min setup

Same sandbox as Rivian. Pre-open the same four tabs — the domain engineer will be watching your screen and needs to see Flow in the context of their subsystem, not the full system tree.

Tab 1Beat 1Requirements, Cooling Subsystem, Table mode

→Go to app.flowengineering.com, candidate-2 org, candidate-2-demo-project
→Left sidebar: Requirements, switch to Tree mode
→Click into Cooling Subsystem node, then switch to Table mode
→Scoped view: only the requirements that affect this subsystem. REQ-35, REQ-28, REQ-34 are inherited from the system level

Tab 2Beat 2Analysis page

→Left sidebar: Analysis
→Pre-load: Heating Model (Python/GitHub), Cooling Model, Reliability Model, Main Chamber Volume (Onshape)
→Leave parked on Heating Model
→When the engineer's Python script runs, Flow reads the output and stores it in the spec automatically (that's the Beat 2 demo)

Tab 3Beats 3-4Testing page

→Left sidebar: Testing, click into Full Verification Test
→Confirm 'Automated Run — PASS' is visible (shows as 'Automat...' truncated) for Humidity Accuracy and Temperature Uniformity
→Confirm the Iterations dropdown shows saved baselines

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

→Left sidebar: Requirements → Heating Subsystem → Table
→Both Beat 5 mutations live here: REQ-35 (power, 1950 W → 2150 W in 5b) and REQ-26 (max temp, 200 → 225 in 5c)
→REQ-26 is in Heating only — Cooling Subsystem will not show that change
→Refresh this tab after each prompt to show the live update

Claude Code — right 40% of screen

Open Claude Code with projects/cowork-flow-interview/ as root. Type “what flow tools do you have?” and confirm 10 flow_*tools appear. Beat 5 framing here is different from Rivian — frame it as a question they'd ask before committing a change, not a governance story for their VP.

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 1 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 1.
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 1 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 resistance

After discovery, ask one opening question to find where the friction lives. Branch based on what they say.

“When your script runs and produces a result — a temperature, a power number, a pass/fail — how does that number end up in the spec today? Do you file it somewhere, or does it just live in the script output?”

A"I don't have time"

"You don't file anything. Your Python script runs, Flow reads the output number, and the spec updates. If you're already running the script, the update already happened. Zero extra steps."

Lean on

→ Beat 2 — show how running the script auto-updates the spec
→ Beat 3 — show how passing tests auto-link to specs

Skip context-setting, go straight to running the script live

B"That's the systems engineer's job"

"The systems engineer (SE) writes the specs — that's their job. But to keep those specs accurate, they need your actual numbers. Right now they email you asking for updates. When your script runs into Flow automatically, they can just look it up. You get fewer interruption emails, not more work."

Lean on

→ Beat 1 — show the scoped spec view first
→ Beat 2 — show how the script run IS the spec update

Lead with what they stop getting interrupted by, not what they gain to do

C"We tried a tool, nobody used it"

"That tool made engineers manually file information — and engineers don't have time for that, so nobody filed anything. Flow reads the information out of the work they're already doing: the Python scripts they already run, the tests they already execute. The AI moment you're about to see removes the last bit of manual effort."

Lean on

→ Beat 5 — AI moment first
→ Beat 2 — show how the script run IS the spec update

Frame it as AI eliminating the filing cost, not engineers adopting a new habit

Demo Run Sheet — Anduril (Task 2) (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

Interviewer plays an Anduril domain engineer — a specialist like a thermal engineer, electrical engineer, or software engineer, probably in thermal or power systems given the sandbox — in sprint crunch. Flow is already licensed. The systems engineering (SE) team uses it. This engineer has been told to log updates into Flow but sees it as the SE's job. Their objection is not price — it's time. "I have 14 PRs queued. When do I have time to update the spec?" Win condition: show that their existing work already IS the update. They don't file the spec manually. Their scripts and test runs do it automatically. The AI moment is a question they'd ask before a commit, not a governance story for their VP. Close with a concrete live action, not a vague next step.

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.“You're using Flow on the systems side — what's been working well about that so far from where you sit?”

Lead positive. Let them say what they like before you dig into friction. Follow up: "What would make it more useful for you specifically?" If they say "I don't really use it" — that IS the barrier, and you're already in Beat 1 territory.

2.“When it comes to actually logging updates into Flow — what are the main things getting in the way of that happening consistently?”

Barrier diagnosis: time, knowledge, resource churn, or license limits. If they say time, that's your Beat 2 (scripts do it automatically). If knowledge, offer a developer day close. If "it's not my job" — that's your opening for the whole demo.

3.“When your thermal model or test run changes mid-sprint, how does that result actually get to the systems engineer — from you directly, from git, or does it land in Flow automatically?”

"From me" or "from git" = Beat 2. They're manually translating their own work instead of it flowing automatically. Their answer is your "remember when you said..." for every beat.

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 (2 min)Tab 1Your requirements, filtered to you

Tab open:Requirements view — Tree mode, subsystem node selected

What this view is	Table mode scoped to a subsystem = what a specialist opens day-to-day Not 400 system requirements — just the ones that affect their work REQ-35 and REQ-28 appear here because the systems engineer scoped them to Cooling — the Cooling lead didn't write them or go find them
What it does	Replaces hunting through a 400-row DOORS export for rows marked with your name When the systems engineer changes a requirement and scopes it to this subsystem, it shows up automatically Each row: value, stage, owner, verification status — no separate tracker
Why this beat is here	Reframes the “extra admin work” objection. If it's 12 requirements, it's a filter, not a burden. Single idea to land: Flow isn't a second place to update things — it's a scoped view of what you already own.

Beat 2 (3 min)Tab 2Your script run IS the update

Tab open:Analysis page

What this view is	Each model card = one analysis job — Heating Model is one Python script, Reliability is another, Onshape is the 3D design file The Model Values panel = the variables inside that one script: what it reads in, what it writes out None of this lives in Flow — each card is a pointer to a file elsewhere (GitHub, Onshape, Excel, MATLAB)
What it does	Thermal script runs → output lands in the spec → requirement knows if it passes, no manual entry 3D design file updates → Flow pulls new mass on re-sync. No export, no ping. The reframe: your run IS the update— you didn't add a step, you removed one
Why this beat is here	Directly addresses “extra admin work.” The objection is real if they imagine manually filing updates. Show it mechanically: run once, Flow updates.That's the behavior change.

Beat 3 (3 min)Tab 3Passing tests close the loop themselves

Tab open:Testing page

What this view is	One row per test — any kind of test. "Automated Run — PASS" = a script ran it automatically. "PENDING" = probably a physical test waiting to be run on real hardware. Flow doesn't care: Python script, someone running the actual chamber, a tech with a multimeter — same ledger When a test passes, Flow links the result to the requirements it covers — automatically
What it does	Replaces: pass test → mention in Slack → systems engineer manually maps it to spec items Now: run the test → result lands in ledger, requirements flip to verified No filing. No ping. The PR is the audit trail.
Why this beat is here	Addresses: “I run the test. I tell the systems engineer. They update the tracker. Why is that my job?” Beat 3 shows it isn't. Bonus: the Iterations dropdown means gate prep is already done — they contributed to it just by running normal tests.

Beat 4 (2 min)Tab 3Gate prep is already done

Tab open:Testing — Iterations dropdown

What this view is	At every major design review, Flow takes a snapshot of the entire project — every requirement, every test result, every number — and saves it with a name The Iterations dropdown lets you switch between any saved snapshot and today in one click Think of it as a time machine: "CoDR Entry" shows you exactly what the project looked like on Dec 10
What it does	Your auditor asks "is this what was signed?" — click the snapshot, show them, click back to now. Not a three-day document hunt. Your sprint work — the tests you ran, the scripts that passed — automatically contributed to the evidence. You didn't assemble anything. The spreadsheet email that goes out the week before a gate? It never gets sent.
Why this beat is here	The “you're already done” beat. Lands fast because engineers have all lived the gate-prep scramble. Show the dropdown switch once and let them do the math.

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. For engineers in the trenches that alignment problem looks like: 'I changed something, I'm not sure what it touches, I should probably check with the systems engineer.' What you've seen in the last 10 minutes is the structured data layer that makes the next 3 minutes possible — because Claude can only reason about your specs if your specs are a live database, not a PDF."

Prompt 5a: pre-commit risk check (45 sec)

Flow view:Flow view: doesn't matter — nothing changes on screen. The aha is the AI giving you a spec risk summary before you push, not a UI update.

I'm the cooling subsystem engineer and I'm about to push a change to the cooling control loop. What requirements in the Cooling Subsystem am I at risk of violating? Pull each requirement's current value and verification status, flag anything failing or within 10% of its limit, and tell me what to double-check before I merge.

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

Prompt 5b: diagnose the failure, don't guess (90 sec)

Flow view:Flow: Requirements → Cooling Subsystem → Table. Find REQ-28 (Temperature Accuracy) — it shows a red X failure. Nothing changes on screen. The aha is what the AI says.

REQ-28 (Temperature Accuracy) is showing a failed verification in the Cooling Subsystem. The requirement says the chamber shall maintain workspace temperature within plus or minus 0.5 degrees C. Look at what's actually in the spec — the current Value field, the linked design value (temp_accuracy_measured_c), and the Check setting — and tell me: is this a real engineering failure, a spec data entry error, or a units mismatch? What needs to be fixed to make this accurate?

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

Prompt 5c: AI writes the Friday update (45 sec)

Flow view:Flow view: doesn't matter — nothing changes. The AI reads your spec and writes prose you can paste.

Write a brief spec status update for the systems engineer covering the Cooling Subsystem. Include: requirements currently passing, anything failing or unverified, the two biggest open items with owner names, and a one-sentence gate readiness assessment. Format it so I can paste it straight into Slack.

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

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

"Pick one requirement that's currently stale in your sprint. We'll link your last test run to it right now. 90 seconds. You'll have done the thing you said takes too long."
"If every engineer on your team did what you just watched once per sprint, the systems engineer stops asking for updates — because Flow already has them. The activation isn't a training program. It's showing this view to five people."
"What are the main things slowing down broader adoption on your team — is it time, is it knowing how, or is it something else? Because the answer changes what makes sense as a next step."
"The AI moment you're about to see — that's the payoff for having structured requirements data. It only works because you and your team ran your models and tests into Flow instead of into a spreadsheet."

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

The activation problem at Anduril is the same problem Pari is solving at the company level: structured data unlocks everything downstream, but only if the people closest to the work contribute to it. My prep workflow for this interview is the same pattern — research monorepo, handbook ingested, sandbox reverse-engineered, agents reasoning over structured context to write the script and the MCP. The insight isn't that AI is powerful. It's that AI is only as useful as the data structure underneath it. That's what Flow gives domain engineers access to — and what a deployment engineer's job is to make real at the team level, not just at the VP level.

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?”

Resistance cheat sheet

Domain engineers resist differently than buyers. These aren't price objections — they're time and ownership objections.

Resistance	Reframe
I don't have time to update the spec mid-sprint	You don't update the spec manually. Your Python script does it. Your test script does it. If you're already running those, Flow already has the update. Nothing extra.
That's the systems engineer's job, not mine	The systems engineer (SE) owns the spec structure. You own the actual numbers. When your thermal script runs into Flow automatically, the SE doesn't have to email you asking for the latest value — they can just look it up. That's fewer interruptions for you, not more work.
We tried a tool like this before and nobody used it	That tool asked engineers to manually file information — and they didn't, because filing it cost more time than it was worth. Flow reads it out of the scripts and tests they're already running. That's the whole point of Beats 2 and 3 — your script run IS the update.
My test scripts already link to Jira tickets, not requirements	The CI commit that runs the test is the same ref Flow tracks. You don't reroute your pipeline — Flow reads the same PR/commit reference. Both linkages can coexist.
I can't modify my CI pipeline to add a webhook	You don't modify your pipeline. Flow's model integrations pull outputs on-demand when you re-run. The trigger is you, not a webhook. Start manual, automate later.
What if I update Flow and the SE overrides it?	Flow has a Change Request layer. If something you've contributed to gets changed, the CR creates an audit trail. You're not losing ownership — you're gaining a paper trail when others touch your subsystem.
I'll look at it after this sprint	That's fine — and expected. The close here isn't 'start today.' It's: before you leave, pick one stale requirement and link your last test run to it. 90 seconds. So you know what it feels like before the sprint ends.

End with the artifact

flow.thedefrag.ai

“Everything I used to prep this — the MCP, the activation plan, the sandbox walkthrough — is live at flow.thedefrag.ai. If you want to show another engineer what we just walked through, that's the link. The activation plan for your team is already built. You don't have to explain it — you just share the URL.”

Different close than Rivian. Not a leave-behind for evaluation — it's a tool they can forward to the next engineer without scheduling another call.