How Flow Works

A "requirement" in Flow is one row in the spec. It has: a statement ("the chamber shall reach 200°C"), a target value (200), a verification status (Passed / Failed / Open), a stage (Draft / In Review / Approved), and an owner.

Requirements are organized in a tree: the top-level system has requirements, and each subsystem below it inherits some of those and adds its own. If the parent changes a constraint, every subsystem that depends on it sees the update automatically. No one has to manually propagate it.

You can view the same data four ways: Table (spreadsheet pivot), Tree (nested hierarchy), Report (rendered spec doc with section numbers, the format an auditor would sign), and Design Reviews (gate-by-gate summary).

The "inherited" rows are spec items that come from a parent system. If you are the thermal engineer and the power budget spec changes at the top level, it shows up in your subsystem view automatically. You see it before you write code against the old number.

This is the piece that was hardest to understand before reading the research. Here is what it actually means:

A thermal engineer writes a Python script that simulates heat flow through a chamber. They run it and get back a number: max_temp_achieved_c = 233.3. Normally they would have to manually copy that into the spec ("REQ-26 says the chamber must reach 200°C; my model shows 233.3°C, so it passes"). Flow automates that copy step.

In Flow, you create an "Analysis Model" that points to your Python script in GitHub. Flow knows which variable is the output. When the script runs (in CI or manually), Flow reads the output and stores it as a Design Value: a named live number inside the spec. The spec item that references that number automatically checks whether it passes.

The same pattern works for CAD files (Flow connects to Onshape, NX, SolidWorks: when the CAD updates, mass and dimensions pull automatically) and Excel spreadsheets (for teams that won't give up Excel).

CI/CD stands for Continuous Integration / Continuous Deployment. In software, it's the automated pipeline that runs tests whenever someone pushes code to GitHub. At hardware companies, that same pipeline often runs the Python simulation scripts too.

The Flow integration works like this: the Python thermal model lives in GitHub. The CI pipeline (GitHub Actions, Jenkins, whatever they use) runs it automatically on every push. Flow has a webhook or a polling hook that reads the script output after the run. So the full chain is:

┌──────────────────────────────┐
│  engineer pushes to GitHub   │
└──────────────┬───────────────┘
               │ CI triggers automatically
               ▼
┌──────────────────────────────┐
│  Python thermal script runs  │
└──────────────┬───────────────┘
               │ outputs a number
               ▼
┌──────────────────────────────┐
│  Flow reads the output       │
│  max_temp_achieved_c = 233.3 │
└──────────────┬───────────────┘
               │ updates live in the spec
               ▼
┌──────────────────────────────┐
│  spec item re-checks         │
│  REQ-26  temp ≥ 200°C  PASS  │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│  systems engineer sees it    │
│  no email, no manual filing  │
└──────────────────────────────┘

From the engineer's point of view: they pushed code like they always do. They did not do anything extra. The spec update was a side effect of their normal workflow.

In the demo, you don't actually show CI triggering live (that would take minutes). You show the result: the Design Value is already there, updated, and the spec item is already marked PASS. The story is "this happened because the script ran, not because someone filed it."

Each spec item eventually needs to be tested. You run a test, get a result (pass/fail, plus a measured value), and that result has to be recorded against the right spec item. The question is: how does it get there without someone copy-pasting from a spreadsheet into a different app?

There are three paths. Be honest about which one is which.

Once a spec item has been approved, you can't just edit the number directly. You have to open a Change Request (CR). A CR is a proposal to change a specific spec item: from what value, to what value, and why. A reviewer approves or rejects it. If approved, the spec item updates and the CR becomes the audit trail.

This is where the AI governance story lands. When an AI client (via MCP) tries to move a spec item from Draft to Released, the Flow API intercepts it and opens a CR instead. The stage does not change until a human reviews and approves it. The AI proposed; it did not execute. The CR is the record of what was proposed and who signed off.

This is the answer to the objection "what if the AI changes something and nobody signed off?" It can't. The governance layer catches it. The API returns 200 (success) but on the server side the stage transition is converted into a CR. You only discover this by reading the requirement back after the write, which is why the MCP does a read-back after every mutation.

Flow's built-in AI is a chatbot panel (bottom right of the app). It can answer questions about the project, generate new spec items from natural language, and decompose requirements into a hierarchy. It runs on GPT-5.4, GPT-5.4 Mini, Claude Sonnet, or Claude Opus (via AWS Bedrock, and they are multi-model). In the candidate sandbox, it is disabled.

The MCP serveris what was built for this demo. MCP (Model Context Protocol) is an open standard for wiring external tools into AI clients. The MCP server exposes 10 Flow tools (read requirements, update a value, update a stage, create a test run, link test to spec items, etc.) by calling Flow's public REST API directly. Any MCP-compatible AI client gets those tools by pointing at one URL.

The distinction between value updates (direct write) and stage updates (triggers CR) is the governance story. An AI client can update numbers freely because that's a data entry. It cannot move something to Released because that requires human sign-off. Flow enforces the difference server-side.

The "bring your own AI" pitch: for customers who want to run their own model inside their VPC (AWS Bedrock Claude, an on-prem fine-tune, anything), the public API is the contract. The MCP is a 400-line demonstration of that contract. They don't need to wait for Flow to ship the AI feature they want. They can wire their own model in over a weekend.