Which local process differences should a shared system preserve?
Format: Article.
Keep a local rule when the business still needs it. Name its owner and test that it follows the shared rules too. Check old labels and habits before you replace them with one common way of working. Do not erase a branch rule just to make a screen simpler.
A shared system needs common meaning, not the same steps at each site. Two branches may use different approval paths but keep one rule. A request stays in review until a named person with authority decides.
Separate a shared rule from a local choice
Write the facts every branch must keep. These may include the request ID, which company owns it, its source, and who does the next step. They are proposed design rules for the business to approve. They are not rules that apply to every company.
Then list what may differ: the reviewer, service calendar, site steps, or an agreed client handoff. Give each choice a named setting and an owner. Do not let it become a side process that no one has written down.
NIST's AI Risk Management Framework stresses the setting where an AI system is used. It also calls for clear roles and duties. [S08] It does not set one process for every branch. Use that idea to ask why a local rule exists and who owns it.
Build a variation register
A variation register is a list of local rules and why they differ. Give each one its own ID. Do not hide several unrelated rules in one paragraph called “local exceptions.” The rows below are hypothetical examples.
| Local difference | Business reason | Owner | Rule every branch keeps | Test case |
|---|---|---|---|---|
| Site access review before assignment | Approved site procedure | Local operations manager | No task released without required approval | Request lacking access review stays held |
| Different finance approver | Entity-specific authority | Entity finance lead | Decision tied to authorized person | Wrong-entity approver cannot release request |
| Alternate service calendar | Current customer agreement | Account owner | Due date comes from an approved calendar | Holiday case uses the correct agreement |
| Old local label for completion | Historical spreadsheet habit | Reporting lead | Shared status meaning remains clear | Label maps correctly or is retired |
Add the source, start date, last check, and branches affected. Is the local rule lasting, short-term, disputed, or still unproven? For a short-term rule, set a review date and say what would end it. Do not invent a legal reason. Get qualified review before saying a law requires the rule.
Decide whether to configure, retain, or retire
Use a setting when the shared process can support the local rule that way. For example, a branch may choose its reviewer from a list of roles with approval rights. It may not choose just anyone in the company.
Keep a separate path when the work or approval rights really differ. A common setting must not hide that gap. Show how the path sends its result back to the shared record. Separate work must still be visible.
Remove a local rule when its owner says it is no longer needed and the new path has passed its tests. Do not remove it just because the central team has not seen it before. Ask staff who use it what would break.
If the reason is still unclear, pause the choice to move that part of the work. Do not build a lasting exception from a guess. Do not delete a needed check without review.
Hypothetical example: two approval routes
A fictional company has a shared request queue. Branch Harbor requires its site coordinator to check access before a vendor assignment. Branch Mesa does not use that step because its approved work takes place in a staffed shared area under a different procedure.
The design keeps one shared request record and a clear release state. Harbor's settings require its written access check. Mesa's settings point to its own approved steps. Changing the branch field must not let staff skip a required approval.
The test uses a copy of the same incomplete request in each branch's approved test space. Reviewers check both paths. Changing the branch must send the request back for review. If staff cannot tell which branch owns it, keep it held. Do not pick the easier path.
Watch for exceptions that outlive their reason
Review the register when a contract, location, source system, or authority changes. An exception approved for a temporary site arrangement should not remain forever because the software still supports it.
Keep the history of old local rules so staff can explain past records. Agree on how a new version applies to future work. It must not rewrite past approval evidence. If you plan to compare branches, ask the report owners to check that their status labels still mean the same thing.
Core Agentic can discuss a custom shared system with written local settings and tests. This example is not a finished enterprise platform. It does not promise one process for every branch. People approve changes. Access must stay limited to the records each role and company may see.
Book a Demo to discuss which branch differences your shared workflow should preserve.
Sources
- NIST: AI RMF Core - AIRC.
These sources describe the named provider or framework. They do not establish a Core Agentic integration, customer result or certification.