Change Impact Engine

The problem, as a story

A supplier stops making one small sensor.

Picture a company that makes infusion pumps, the machines in a hospital that push medicine through an IV line at a set speed. Inside each pump is a small pressure sensor. It watches the IV line, so the pump can sound an alarm if the line gets blocked.

One morning the supplier says they are discontinuing that sensor. The company has to switch to a new one. Here is how that usually goes.

Monday
An engineer files a change request: "Replace the pressure sensor with one from a new supplier."
Monday
The coordinator emails the leads for electrical, firmware, mechanical and testing: "What does this affect on your side?"
Tuesday to Thursday
Each lead digs through their own tool and replies with a spreadsheet. Each one sees only their own piece.
Next week
Someone merges the answers, books a review meeting and starts chasing signatures.
Months later
An auditor asks why the blockage-alarm test was never run again on the new sensor. Nobody connected the two.

Why it's hard

The answer is split across three tools that don't talk to each other.

What the product must do

The requirements. "Check the IV line pressure at least 10 times a second." Owned by the systems engineers.

What the product is made of

The parts list. The sensor sits on the control board, and the control board sits inside the pump. Owned by the electrical and mechanical teams.

How each promise is proven

The tests. "Block the line and time how fast the alarm goes off." Owned by the test team.

The connections between those three live in people's heads and old spreadsheets. When one person forgets a connection, a test that should have been re-run gets skipped. In medical devices, the FDA expects every one of these reviews to be documented and traceable, so a missed connection is a real problem, not just a slow one.

How it works

Same sensor change. The system follows every connection for you.

Every connection is stored once, in one place: this part sits inside that board, this part is what makes that requirement true, this test checks that board. When something changes, the system walks those connections out from the change and collects everything it reaches.

1. The change Pressure sensorNew supplier

2. What it sits inside Control boardholds the sensor The whole pumpholds the board

3. What it has to do Check pressure 10 times a secondthe sensor is how the pump does this

4. What to test again Blockage alarm testruns on the control board Full pump checkruns on the whole pump

5. Who signs off Electrical leadFirmware lead Mechanical leadTest lead Configuration manager

What changes for the people involved

	Today	With the engine
Finding what's affected	Four people search four tools and reply over a few days	Found the moment the change is filed, with the reason for each item
Who has to approve	Whoever the coordinator remembers to email	Exactly the owners of the affected items, plus configuration management
Tests to run again	Depends on someone remembering the connection	Listed on the change, so they can't be skipped quietly
If a part changes in a tool	Nothing happens until someone notices	A review opens by itself
The paper trail	Scattered across email and spreadsheets	One log, and any edit to it is detected

The working screen

One page to review a change.

This is the real app running the sensor example. Every row says what the item is, why it is affected, and who owns it. The short ID on the right is the code an engineering tool would use.

The review page for the pressure sensor change: one requirement, two assemblies and two tests to re-run, five approvers with three approved, and the change log.

Top bannerThe change, its status and the counts: 1 requirement, 2 parts, 2 tests to re-run, 3 of 5 sign-offs.

What this change affectsEvery affected item, why it's affected, how many steps away it is, and who owns it.

Sign-offsOnly the people the change was sent to can approve it, and each person votes once.

Change logEvery action, who did it and when. The green badge at the top means nobody has edited the history.

Under the hood

Built the way a company would need it to work.

The demo is small, but each piece solves a problem a real company would hit. Each card names the technique once, then says what it does.

Three separate systems

Like the tools a company already has

Requirements, parts and tests each run as their own service with their own data. They only meet through the connections, the same way a real company's tools stay separate.

One table of connections

The map nobody had

Every "sits inside", "makes this true" and "is tested by" link is stored in one place. A single database query follows the links outward and records how far away each item is.

Outbox events

Changes never get lost

When a part is edited, the edit and a "this changed" message are saved together. Either both happen or neither does, so the system never misses a change or reacts to one that didn't happen.

Safe to retry

No double work after a crash

Each message is marked once it's handled. If it arrives twice, the second copy is skipped. If it keeps failing, it is set aside with the error after three tries instead of blocking everything else.

Exception queue

Stuck work gets an owner

A message that failed three times, a sign-off waiting more than five days, or a change to a part with no links each lands in one queue with a named owner. Retry it, or close it with a reason. Overdue items clear themselves when the change closes.

Approval routing

The right people, nobody extra

The owner of the changed part, the owner of every affected item, and configuration management. One rejection stops the change.

Tamper-evident log

A history you can trust

The database refuses edits and deletes on the log. Each entry is also sealed with a fingerprint of the one before it, so changing any old entry breaks the chain and the check catches it.

Tested, not just demoed

The sensor example returns exactly the five items above
A full change goes from filed to approved, and one rejection stops it
People who aren't approvers can't vote, and nobody votes twice
Editing a part opens a review by itself
A repeated message is not handled twice; a failing one is set aside after three tries
The log refuses edits, and the fingerprint check catches tampering

Tools

Python and FastAPI for the services. SQLite with recursive SQL for the connections. pytest for the 13 tests. Docker, set up to run as a locked-down, non-admin container.

Next on the list: PostgreSQL, a real message queue on AWS, sign-in for approvers, and an automated build that scans for security issues.

What it's worth

A rough model for a mid-size device maker.

These are my estimates, not measured numbers. They're here to show the size of the problem. Swap in a real company's numbers and the math works the same way.

What I assumed

Changes a year (60 a month)	720
Hours to review one change by hand	6
Hours with the engine, to check its answer	1
Cost of an engineering hour	$75
Hand reviews that miss a test	2%

What that adds up to, each year

Hours saved: 720 changes x 5 hours	3,600 hours
Cost saved: 3,600 x $75	$270,000
Missed re-tests caught: 2% of 720	About 14

The hours are the easy number to see. The 14 missed tests are the bigger deal: each one could turn into an audit finding or a problem with a pump in a hospital.

When one part changes, what else has to change?