When a Business Rule Changes, What Needs Another Review?

A customer changes their details. The service accepts the update, but the confirmation screen reads a reporting copy that has not caught up. It shows the old details as the confirmed change. This illustrative case shows how an approved architecture can acquire a new use that needs its own review.

A scoped review identifies the affected decision, missing evidence, and what can proceed. When a coding agent extends a workflow, reusing an approved component can still create a new obligation.

Follow the new use back to its assumption

The original workflow has an invented requirement: customers must be able to submit updates while downstream reporting is unavailable. Reporting may lag, provided pending status, duplicate handling, and recovery ownership are explicit. The team approves a queue for that purpose.

Now a confirmation screen is added. It reads the reporting copy, but a new business rule says the confirmation must show the details from the update the customer just submitted. Older details must not appear as the confirmed update.

What changes when reporting becomes a confirmation source

Review question	Original workflow	New confirmation use
Required outcome	Accept updates during reporting outages	Show the accepted details for this submission
Where is delay acceptable?	Downstream reporting	Not as older details presented as the confirmed update
What needs support?	Delivery, pending status, duplicate handling, recovery	Confirmation tied to the accepted submission

The overlooked dependency is the confirmation's source of data. A constructed sequence exposes it:

1. Reporting holds the customer's old details.
2. The write service accepts new details; queued delivery is pending.
3. The confirmation reads reporting and displays the old details as the confirmed update.

Under those conditions, the screen violates the invented requirement. This is a reasoning example, not an observed incident or test result. Whether an actual implementation permits that sequence still needs evidence.

Ask what the old checks actually establish

Availability, delivery, and retry checks address the original workflow. Even if those checks pass, they do not establish that the confirmation shows the accepted submission while reporting is behind.

Break the new rule into reviewable conditions: the update was accepted; the confirmation refers to that submission; the displayed details match its accepted values. If acceptance is unresolved, the screen must not claim completion. The product owner must agree that pending behavior.

These are conditions for satisfying one business rule, not a list of implementation tasks. The evidence must establish each condition at the time the confirmation is shown. Missing support leaves the new path unassessed; it does not prove that every existing use is defective.

Keep the reporting queue; review the confirmation path

One design response is to obtain the confirmation from the authoritative write path's accepted update, while reporting stays asynchronous. That response needs technical review: echoing what the customer requested would not, by itself, establish what the service accepted.

The technical reviewer examines the accepted result and its relationship to the submission. The product owner confirms what customers should see when acceptance succeeds, fails, or remains unresolved. Customer or partner engineers implement the agreed response.

A concrete acceptance check follows the troublesome sequence: hold reporting on the old values, submit different values, and keep queued delivery pending. Confirm that the screen shows the accepted values for that submission. When acceptance is unconfirmed or rejected, check that the screen does not show a completed confirmation.

A filled review record

The following record captures the proposed disposition of this illustrative review:

• Old approval and scope: asynchronous delivery of accepted profile updates to reporting; pending status, duplicate handling, and recovery remain required.
• Changed requirement: confirmation must show the just-submitted update's accepted details, never older reporting details as that update.
• Affected assumption: a reporting copy allowed to lag is now used for immediate confirmation.
• Earlier checks address: the original reporting requirements; they do not assess the new confirmation path.
• Missing evidence: the screen's actual source, its connection to the accepted submission, and outcomes under delayed reporting or unresolved acceptance.
• Proposed resolution: use the accepted write-path result for confirmation; retain queued reporting.
• Owners: product owner confirms customer behavior; technical reviewer validates the design; engineering owner supplies implementation and test evidence; release owner checks the condition is closed.
• Decision: proceed with the reporting architecture within its existing scope and conditions. Withhold approval of the new confirmation path until review and acceptance evidence are complete.

The aim is to focus work on the affected path and expose the release condition before customers encounter a mismatch. The record makes that work actionable without reopening every architecture choice.

Bring one changing workflow

Keller can work alongside an internal team in a scoped engagement: clarify the business rule, examine affected decisions and evidence, and prepare a practical review and engineering handoff. Our research informs the review method; Archangel's Decision Trace connects decisions with supporting context, evidence, and reviewer action where it fits the engagement. Customer or partner engineers own implementation.

Talk to the team about one workflow and the change it needs to accommodate.