A release or remediation proposes a source change.
Change
Thursday's change board has a release that touches the pricing tables. The team says the blast radius is small. I am approving it, and I want to see that for myself.
The change board member
What can this proposed change reach?
The product at work
The change ticket for Thursday's board: one edit to the normalisation step.
Before and after, read from the code: divided by ten, then by one hundred.
The reach fills in: month-end total and management report touched, source extract left alone.
The Change-impact brief clipped to the ticket, for the board, with one batch step still unread.
What usually happens
The developer lists the tables the change writes to, and someone remembers a report that reads one of them. After that there is a search through job code and a hope that the diagram is current, and in the end the approval rests on who was in the room.
With a reading
With a reading, the change is read against the current code and its reach is drawn before it goes in, so you can see the fields and results downstream that it can touch and the ones it leaves alone.
The changed relationships and their bounded downstream structural reach, separated from unchanged and unresolved paths.
The reach is read from the code as it stands, before the board sits. Approving it remains the board's call.
Who it is for
For the change board member, release manager or risk owner approving a change to a system they did not write, backed by the Finding register.
What to bring
The current code and the proposed change, with the configuration and job schedules that connect them.