Rivian Run Sheet

Log in to app.flowengineering.com → select the candidate-2 org → open candidate-2-demo-project. Left sidebar → Requirements. Top of the requirements panel, switch view mode to Tree. Expand the root so the full hierarchy is visible: TestEquity 123H at top, then Chamber Enclosure, Control & Sensors, Humidity Control (which has Cooling and Heating as children).

The Requirements view is the central artifact in Flow — it's where every spec, constraint, and design criterion for the product lives. Tree mode renders that as the system architecture: each node is a subsystem, each subsystem holds the requirements that scope what it must do. The view-mode switcher (Tree / Table / Report / Design Reviews) at the top is critical to understand. Same underlying data, four ways to look at it. Tree shows hierarchy. Table shows a flat list with columns. Report renders it as the numbered spec document a VP would sign. Design Reviews shows it organized around gate ceremonies.

It replaces the dual-tool setup most teams have today (Word/Confluence spec doc + DOORS or Jira for requirements tracking). One place. The numbered document and the live database are the same data. Each node rolls up a count of how many requirements it contains, so a systems engineer can see at a glance which subsystems are heavy and which are light.

Beat 1 lands the core thesis: the spec doc isn't dead, it just stopped being the source of truth. You start here because if the interviewer doesn't accept that requirements can be a living artifact (not a quarterly Word doc), nothing else in the demo lands.

Duplicate Tab 1. In the requirements panel, click into the Cooling Subsystem node (not the root). Switch view mode from Tree to Table. You're now seeing only the requirements scoped to Cooling — not the whole system, just one subsystem's slice. Columns: Value, Stage, Change Requests, Owner.

Table mode is what a domain engineer (the Cooling lead, the BMS lead, the thermal team) actually opens day-to-day. It's a flat list of just the requirements they own or inherit, with the values they care about visible without clicking. The key visual is the inheritance indicator on certain rows (REQ-35, REQ-28, REQ-34) — those constraints didn't originate at the Cooling level, they came down from the parent system.

Shows requirements flow down without the Cooling lead having to assemble it manually. When the Head of Systems Engineering changes REQ-28 at the root level, the Cooling lead's view updates. When they click any single requirement, a side panel opens showing value, verification status, owner, stage, change-request history — one record for everything about that requirement.

Beat 2 closes the loop on Beat 1. If the spec is the live artifact (Beat 1), this is what propagation looks like in practice. The interviewer will be testing whether you can articulate trace-by-default — automatic — vs. trace-by-audit (find the breakage after the fact). For Rivian specifically, this is where a cell chemistry change at the system level reaches the pack thermal lead automatically instead of through email.

Left sidebar → Parameters → Analysis. You'll see a list of analysis models down the left side: Heating Model (linked to a Python script on GitHub), Cooling Model, Reliability Model, Main Chamber Volume (linked to an Onshape CAD file), and a few others. Click each model once to pre-load its detail pane (analysis models can take a beat to render the first time). Leave it parked on the Heating Model when warmed.

This is Flow's connection layer to the engineering tools your team already uses. Each 'model' in this list isn't something you build inside Flow — it's a pointer to a real artifact that lives somewhere else: a Python script in GitHub, a part in Onshape, a sheet in Excel, a calc in MATLAB. Flow reads the inputs and outputs of each model and exposes them as Design Values — numbers that the requirements record knows about and references.

When the Python thermal model runs, the output (max_temp_achieved_c = 233.3) becomes a Design Value inside Flow. The requirements that reference that Design Value automatically know whether they pass or fail. When someone bumps a parameter in Onshape and re-syncs, Flow pulls the new mass automatically. Verification stops being a quarterly campaign and becomes a continuous side-effect of designing.

This is Beat 3 because it's where most demos either land the aha or lose the room. If they get this — that the analysis tools your team already runs become the verification engine, with no rip-and-replace — every other beat is downstream of this insight. For Rivian specifically, they already have SimOS chaining thermal/structural/electrical sims on commit hooks. The compute is solved. What Flow adds is requirements traceability on top of that pipeline.

Left sidebar → Verification → Testing. You'll see the Full Verification Test plan with four test cases listed. One of them shows 'Automated Run — TC11 PASS' in the Last Run column — that's the visual you'll point at. Above the test list, find the Iterations dropdown. By default it shows 'Current Iteration.' Click it, you'll see saved baselines including 'CoDR Entry (10 Dec 2025).' Make sure you can see both the test list and the dropdown without scrolling.

The Verification view is Flow's test ledger. Every test case (whether it's a Python script, a bench procedure, a tech with a multimeter, a CI job) is a row. The Last Run column shows what happened most recently. The Iterations dropdown is the most important thing on this page — it's how Flow does named baselines. Every design review (CoDR, PDR, CDR, Design Freeze) creates a snapshot of the entire requirements + verification state at that moment, and you can switch between any baseline and current with a click.

Replaces the manual evidence-assembly that happens before every gate. Today the evidence package is a person pulling test reports, model outputs, and sign-offs from a dozen tools into a single presentation. With Flow, the evidence is the system state. 'Is this what I approved at CoDR?' becomes a one-click diff — switch the iteration to CoDR Entry, see what changed, switch back to current.

Beat 4 closes the verification loop and sets up Beat 5. If Beat 3 showed how analysis outputs flow into requirements, Beat 4 shows how test results do the same — and how named baselines turn audit prep from a week-long sprint into a query. For Rivian, the named-baseline story matters because Design Freeze Reviews require sign-off across 12+ subsystem leads, each of whom currently aggregates their own evidence.