One Business Rule Changed. Which Automations Need Review?

Start with the changed agreement

Consider this synthetic example, created to illustrate change planning. A service team previously required a customer reference before accepting a request. It now proposes allowing people to submit without that reference. The goal is to let staff investigate incomplete requests rather than reject them at the form.

Removing the required-field check seems small. But earlier decisions assumed that every accepted request could be matched by reference. Routing, reminder wording, review instructions and reports may all depend on that assumption. Accepting a request without a reference does not establish which customer owns it.

In Chapter 14 of Brain of the Firm, Stafford Beer examines how decisions constrain one another and how changed choices can reopen a wider problem. The register and tests below are our practical application of that idea. They are a proposed method, not a reported AIify It deployment.

Record why a choice was valid

A decision record should explain what was agreed and why it was reasonable. Give it a short reference, an accountable owner, the approved source or evidence, the alternatives considered, and the assumptions on which it depends. Record its scope and effective version, plus the change that would trigger reconsideration.

For this example, the original acceptance decision relied on the reference being available at intake. A matching decision then relied on that acceptance rule. Connect them explicitly: if the requirement changes, the matching owner must check whether their decision still holds.

Keep this distinct from assigning implementation work. A task says who will change the form. A decision dependency explains why the matching policy must be reconsidered even if its code has no connection to the form. Likewise, a shared-component consumer list finds technical users; it may miss a reviewer following an old instruction.

Keep temporary assumptions from becoming permanent facts

A dependency can begin with a guess rather than an approved, evidenced standard. Label that distinction explicitly. A named owner and review date do not make an unsafe default acceptable; first check whether using it at all is permitted for the proposed scope.

Extend the synthetic reference-free intake example with a provisional planning estimate: eight minutes to identify the customer. The team has not measured representative cases. The following temporary-default record prevents that convenient number from silently becoming an operating fact.

• Status and scope: provisional assumption, introduced on 1 October in this invented record; for sizing a draft-only test, not customer promises, staff quotas or unattended routing.
• Owner and evidence gap: the operations owner needs representative identification times, including ambiguous cases, interruptions and repeat checks. Eight minutes is an assumption, not an observed average.
• Consumers: reviewer-capacity estimate, expected waiting time, cost forecast and decision to expand intake. Each must retain the provisional label.
• Review trigger: review on 14 October in this example, or sooner if an ambiguous case or changed intake mix undermines the estimate. The dates illustrate a record; they are not a recommended universal review interval.
• No new evidence at review: mark still unknown, notify the dependent decision owners and keep expansion that relies on the estimate blocked. Do not silently renew it as a validated standard.

Close the evidence gap before closing the review

An eventual review can support the assumption for a stated scope, revise it, retire it or leave it explicitly unknown. Record the evidence and decision, then reconsider every consumer before changing the value. A revised duration may change capacity and cost without changing the rule that customer identity must be established before routing.

Frederick Winslow Taylor describes partly guessed task standards that were meant to be revisited but were lost from view in his Testimony Before the Special House Committee, pages 270–271. Francisco R. Sagasti, in chapter 25 of Planning for Human Systems, page 335, argues that planning horizons depend on the issue and its changing conditions. The provisional record and event-based triggers here are our modern adaptation, not support for Taylor’s pay or work-rate practices.

Work through the rule-change register

The following is a worked synthetic register. Treat the intake proposal as awaiting approval. Each dependent choice has a review status, an owner and a proposed disposition. These are illustrative decisions for this fictional workflow, not rules to apply automatically elsewhere.

• Acceptance rule: needs reapproval by the process owner. Proposed revision permits a blank reference at submission and records the request as awaiting customer identification. The effective version must say whether this applies to older waiting requests.
• Matching rule: needs evidence from the data owner. Exact matching for a supplied, valid reference can remain. A blank reference must not trigger an automatic name-based association; the owner must approve any additional matching method separately.
• Routing rule: needs reapproval by the operations owner. Reference-free requests need a named review destination instead of the customer-specific route. The reviewer must establish the customer before work can enter that route.
• Reminder wording: needs reapproval by the communications owner. The old missing-reference request no longer applies to every blank field. A reviewer may still need more identifying information, using an approved request appropriate to the case.
• Report classification: needs reapproval by the reporting owner. A permitted blank reference should appear as awaiting identification, rather than invalid intake. The report must still expose unresolved work so acceptance does not look like completion.
• Access boundary: remains valid after the access owner checks it. Reviewers use only the records already permitted for their role. An optional field provides no authority to broaden searches or expose another customer’s information.

Follow dependencies until they settle

Review both direct and indirect effects. Changed routing may send more work to the review queue. If the team cannot handle that work within its agreed response window, the process owner may need to revise the intake proposal or arrange capacity before approval. Record that unresolved dependency rather than assuming the original proposal must proceed.

Ask owners to mark each choice as still valid, needing evidence or needing reapproval. A choice can remain valid, but the record should explain why. When an affected owner identifies another dependency, add it and review the consequence. Stop expanding the map when the relevant owners can account for the affected decisions and the outstanding uncertainties are visible.

AI can suggest places to inspect across approved documents and configuration. A person still needs to confirm the dependencies and resolve disagreements. An apparently complete generated list does not establish complete impact coverage.

Turn each dependency into a check

Before rollout, pair each approved change with an observable expected result. The synthetic test plan below assumes the proposed register has been approved. It specifies what to test; it does not claim these tests have run.

• Valid supplied reference: the request reaches the same verified customer and permitted route as before. Check the saved destination, not only the matching response.
• Blank reference with one plausible name match: intake succeeds, customer association stays unresolved and the assigned reviewer receives the case. A plausible name alone must not attach it.
• Blank reference with several plausible matches: the review item preserves the ambiguity without showing records outside the reviewer’s access.
• Unknown supplied reference: the request follows the separately approved unknown-reference path. Making absence acceptable must not turn an invalid value into a confirmed match.
• Waiting request from the earlier version: apply the agreed transition rule. Recheck any queued reminder so obsolete wording cannot be sent merely because it was scheduled earlier.
• Report output: awaiting-identification items remain visible and are not counted as completed customer work. Reconcile the report with the underlying test requests.

Release the agreement and its implementation together

Keep the approved rule, dependent decisions, reviewer instructions and test expectations connected to the implementation version. Resolve or explicitly block outstanding decisions before enabling the affected path. Confirm who authorizes release and who can pause it if the observed result differs.

Preserve the superseded record with its effective period so someone investigating an older request can understand the rule it used. After the change, inspect representative accepted outcomes and unresolved cases. The useful finish line is a consistent operating agreement across the workflow, with evidence that the implemented behavior matches it.