ProductHow a hardware change moves through ProductFlo.
Hardware changes don't live in one file — they ripple through schematics, firmware, BOMs, mechanical parts, suppliers, and reviewers. This doc walks through the mental model and three scenarios that show every screen doing real work.
01The mental model
Every hardware program in ProductFlo is a graph of artefacts — schematics, board layouts, firmware, BOM lines, mechanical parts, suppliers, test fixtures — connected by the real relationships between them. A change to any node makes the graph recompute what else needs to move.
Graph of truth
One connected picture of the product. main-board.kicad_pcb routes to pinmap.c which drives J12 which is sourced from molex.
Agents
Always-on workers watching suppliers, BOMs, firmware diffs, DFM rules. They draft ECOs when they detect risk — but they don't merge.
ECOs
A proposed change. Cascaded automatically down the graph so every affected artefact is patched, reviewed, and shipped together.
Reviewers
Code-owners per discipline (EE, ME, FW, MFG) sign off on the parts of the cascade they own. No ECO merges without the right approvals.
02Who's on the graph
ProductFlo is a shared surface for four personas plus the agent fleet. The doc follows these characters through every scenario.
03The five screens
Five surfaces, one graph. Each screen answers one question and hands off naturally to the next. You can reach any of them from the top nav on any page.
04Lifecycle of a change
Every change — whether an agent or human started it — moves through the same six stages. The next three scenarios show this lifecycle running with different actors and different stakes.
Supplier EOL — J12 connector hits last-time-buy
The most common failure mode: a part goes end-of-life while your team is heads-down on something else. Today you find out at the next BOM scrub — three weeks late. In ProductFlo, supply-watch sees it the day the notice lands.
A supplier feed fires. The agent drafts an ECO.
supply-watch scrapes supplier APIs continuously. Molex posts an EOL notice for MOL-43025-0400 (the J12 connector on main-board) with last-time-buy by Q3 2026. Current stock covers ~4 weeks of builds.
The agent scores risk, finds MOL-43025-0600 as a pin-compatible 6-pin successor with >12k units in stock, and drafts an ECO — it does not merge.
Impact view scopes the change across 5 disciplines.
Before committing, Mira opens Impact on the J12 node. She sees 7 artefacts affected across 5 disciplines: the PCB re-routes 6 segments (auto-patchable), firmware's pinmap.c shifts one ADC channel (auto-patchable), BOM swaps the line and adds +$2.40 unit cost.
Two items need human eyes: Kavya's chassis cutout widens +0.8mm, and the MFG test fixture's pogo-pin map needs to be re-flashed.
Every downstream patch is bundled in one ECO.
The ECO page shows the full cascade: a +net_pwr_in re-route diff in the PCB, a -#define ADC_CHANNEL_3 / +ADC_CHANNEL_5 diff in firmware, a BOM row update, and a mechanical cutout adjustment. The stepper shows state: drafted → scored → checks passing → in review.
Code-owners approve their discipline.
Devon (EE) and Kai (FW) both mark approved. Kavya (ME) posts a changes requested note: "Cutout +0.8mm is fine structurally but I'd like R1.0 → R1.5 fillets to match the rear panel."
The author replies, patches the ME part, re-runs checks. All three disciplines now green.
Merge propagates the cascade atomically.
One click. Every tool-side artefact updates in lockstep — Altium opens a PR for the PCB re-route, the firmware repo takes the pinmap.c diff, Windchill picks up the new BOM, SolidWorks takes the chassis rev.
Caught 3 weeks before last-time-buy. One ECO instead of a cascade of 7 JIRA tickets across 4 teams.
Thermal violation — regulator runs hot on the DVT build
Mira sees a regulator hitting 94 °C in the DVT thermal log. She suspects the cap bank. This scenario shows how a human-initiated change uses the same surfaces as the agent flow.
Rewind the graph to find when the regulator circuit last changed.
Mira opens Graph View, scrubs the time-warp slider back to the last thermal-passing DVT build. She diffs against now: C7 changed from 10µF to 22µF in ECO-2038. The graph highlights the regulator node and its immediate neighbours.
Ask the impact view "what if I revert C7?"
Impact view simulates the patch before anything is committed. Reverting C7 to 10µF is auto-patchable in schematic and BOM, but the dfm-auditor agent flags a ripple risk on the load transient and recommends pairing the revert with a new ferrite (L4 upstream).
Propose the ECO with both changes bundled.
Mira accepts the auditor's suggestion. The ECO now contains: C7 revert, L4 ferrite add, a firmware threshold bump in the brown-out handler. Three diffs, one atomic change.
Automated checks run before human review.
dfm-auditor posts DRC clean; bom-optimizer confirms lead time; fw-validator runs the firmware diff through unit tests. The stepper advances from scored → checks passing only when all three pass.
One merge, three tools updated.
Merge propagates the schematic, firmware, and BOM in a single transaction. DVT rebuilds, thermal logs go green.
Root cause surfaced by rewinding the graph, not by tracing PDFs across three repos. The agent caught the downstream ripple the engineer might have missed.
Simultaneous edit — two ECOs touch the same net
Eventually two changes collide. supply-watch's J12 swap (eco-2041) and Mira's power-rail tidy (eco-2044) both touch NET_PWR_IN. Normally this is where the change process breaks down. Here, it's a routine merge.
The merge gate detects the overlap.
When eco-2044 enters the merge stage, the gate notices eco-2041 has an open patch on the same net. It pauses both, opens a conflict record, and pings both authors.
See Base · A · B as real schematics, not textual diffs.
The resolver renders the three versions of the net: Base at the common ancestor (dvt-03 @ 8f21c4), A at eco-2041, B at eco-2044. Humans can actually see what each branch did.
An AI proposal — humans pick or edit.
graph.merge proposes "combine both — 6-pin J12-ALT-B with TVS + shield." Confidence 0.84. Rationale names which parts of A and B it kept and why.
Authors can accept the combine, take A only, take B only, keep base, or open a playbook and hand-edit. Every conflict has an explicit human decision — nothing auto-merges across a conflict boundary.
Both authors converge in the hunk-level chat.
Mira: "Adding TVS because we saw 24V transients on bench. Keeping J12 at 4-pin." supply-watch: "Original J12 is EOL — ALT-B is 6-pin but pin-compat for the first 4." The AI proposal reconciles both — they accept.
Commit resolution → both ECOs merge.
The resolver emits a single combined patch. Both ECOs are marked merged; the cascade propagates downstream to firmware, chassis, and test. The graph now records one consistent truth.
A collision that would have triggered a three-day email thread resolved in one review session. The AI doesn't decide — it proposes, and the authors ratify.