HQ Rules and Local Overrides: Governance for Franchise AI

Prerequisites

Before designing a local-exception process, write down which decisions are genuinely central and which may vary by location. This guide focuses on exceptions to operating policies and prices: for example, a temporary departure from a standard service rule or a location-specific price adjustment. It does not cover payment authority, customer follow-up design, or staff scheduling. Those workflows have distinct risks and need their own controls.

You will need a named owner for the relevant headquarters policy, an operator who understands the location’s constraints, a record of the current rule and its effective date, and a system or log that can preserve a request and its disposition. Decide where a proposed change will be held before approval and where an approved change will be recorded. A chat thread alone is a poor source of truth because it can separate the decision from the exact change being authorized.

Also define what the AI is allowed to do. A useful starting boundary is that it may summarize a request, check it against stated rules, and prepare a proposed exception. It must not change a live policy or price before an authorized person approves the exact proposed change. If your organization has not yet agreed on basic AI ownership and decision boundaries, first review [a practical governance framework] (https://www.padiso.co/blog/ai-governance-framework-that-wont-slow-your-team-down/). Remove the space before the opening parenthesis when using this link.

Warning: Approval is not a general permission to improvise. It must apply to a specific location, rule or price, change, and validity period. If any of those details change after review, send the revised proposal through review again.

Step 1: Separate the HQ rule from its local parameters

Start with a plain-language inventory of the policies and prices the AI-supported process may encounter. For every item, identify the part that must remain consistent across the network and the part that can be varied through a controlled exception. If this distinction is vague, reviewers will end up debating intent from scratch for each request.

For a service policy, the central rule might define the standard customer promise, while local parameters might include an opening window or a service-area boundary. For a price, the central rule might define the approved price list and the circumstances in which a deviation can be considered. These are examples of how to structure a decision, not claims about what any particular franchise should permit. The business must define its own permissible ranges and reasons.

Represent the distinction in a small rule record. Useful fields include a stable rule identifier, a human-readable name, the current version, the effective date, the central requirement, permitted local variation, the person or role that can authorize an exception, and the evidence needed to verify its effect. Avoid putting all of this into a single paragraph if the workflow needs to compare a proposal against specific conditions.

A rule such as local managers may adjust pricing is too open-ended to review consistently. A more reviewable rule says which item or service can vary, what limit applies, which locations are eligible, when the variance starts and ends, and which conditions require escalation. The allowed range must come from the business, not from the model’s interpretation of past examples.

Step 2: Define exception classes and boundaries

Group requests by what changes and by the risk of applying the change. A narrow, time-limited departure from a local operating procedure may be different from changing a price across several locations. The purpose of classification is not to build a complicated taxonomy. It is to prevent a low-impact request from silently acquiring the authority of a broad or long-running change.

For each class, specify what can be proposed, what information is required, who reviews it, and what is never eligible for local override. State how to handle a request that combines several changes. If someone asks to alter a customer-facing policy and a price in one message, split it into separately reviewable changes unless there is a clear reason to assess them together. Separate decisions make it easier to approve one part and decline another without losing track of either.

Set boundaries in business terms. A request may need to name one location, one defined group of locations, or the whole network. It may need to identify an exact product, service, or policy clause. It should state the proposed start and end, the reason for the exception, and the expected operational effect. Avoid open-ended terms such as temporary without a date or competitive adjustment without a stated basis and limit.

Some requests should be rejected or escalated rather than converted into an exception. Examples include a request that conflicts with a non-negotiable HQ rule, lacks the information needed to assess its effect, or attempts to turn a one-location decision into a network-wide precedent. Define these boundaries before launch. Otherwise the AI may present an incomplete request as if it were merely a routine variation.

Step 3: Create a request record before asking for a decision

Use a consistent request form or structured message. At minimum, capture the requester, location identifier, rule or price identifier, current value, proposed value, start date, expiry date, reason, supporting information, and the person responsible for carrying out the change. Include a field for the AI’s summary, but preserve the original request as well. A summary is convenient; it is not a substitute for the request that a reviewer must authorize.

Use explicit units and formats. A proposed price should identify the relevant item or service, currency, and whether the value is before or after any applicable additions used by the business. A policy change should quote or point to the exact rule version and state the replacement behavior. Dates should include a timezone or a clearly defined local-time convention when timing affects execution. Ambiguous values are not harmless clerical details; they can change what a reviewer thinks they are approving.

Add a request status that distinguishes draft, submitted, needs information, under review, approved, declined, expired, and completed. Do not let a message saying approved stand in for a status update that lacks the approved payload. A reviewer’s decision should be stored with the request record and linked to the version of the proposed change they saw.

Where the request arrives conversationally, have the AI extract fields and show them back to the requester for correction before routing. The confirmation should make omissions visible. If the requester changes the proposed value after confirmation, create a new version rather than silently editing the submitted version. This modest versioning discipline helps reveal whether an approval still matches the action that is about to occur.

Step 4: Check the request against the central rule

Compare the proposed change to the applicable HQ rule, not just to the requester’s description of it. The process should resolve the rule identifier and version, retrieve the current allowed boundaries, and identify any missing fields. If the rule cannot be found or its current version is uncertain, stop and route the request for clarification. Guessing from a similar policy can produce a plausible but unauthorized answer.

The AI can make the comparison legible by returning the relevant rule, the proposed departure, and the conditions that appear satisfied or unsatisfied. Keep the output grounded in explicit inputs. It should distinguish a direct match from an inference, and it should not invent a permissible range where the rule provides none. A reviewer should be able to inspect the comparison without accepting a recommendation merely because it sounds confident.

Route straightforward requests differently from boundary cases. A request within a pre-authorized local range may follow the organization’s standard process, if such a range has actually been established. A request outside that range, or one that changes the rule itself, should go to the designated decision-maker. If no authorized exception exists, the system should hold the request rather than treat the absence of a restriction as permission.

Pro tip: Keep the policy text or structured rule that was used in the comparison with the request record. A later policy update should not make it impossible to reconstruct what the reviewer saw when deciding an earlier request.

Step 5: Prepare a bounded, reviewable proposal

Have the AI produce a compact change proposal rather than a free-form recommendation. The proposal should state the current value, requested value, location scope, relevant HQ rule, reason, start and expiry, known consequences, unresolved questions, and the evidence supplied. If one element is unknown, label it as unknown. Do not let the model fill gaps with a likely value drawn from context.

The reviewer needs to see the difference between facts supplied by the requester and conclusions produced by the AI. For example, the requester may provide a date and a reason, while the AI may identify a mismatch with a price rule. Preserve those distinctions. If the proposal includes an impact estimate, show the assumptions and arithmetic used; do not present a forecast as an established result. A reviewer can then accept, amend, ask for evidence, or decline based on the actual business decision.

For changes to prices, the proposal should identify exactly which item, service, location, and time period would be affected. For policy changes, it should name the specific behavior being changed and the behavior that remains unchanged. A vague instruction such as make the local offer more flexible is not executable and should not reach approval as a final payload.

The approved object should be as narrow as the request allows. Avoid bundling unrelated exceptions into one approval because a reviewer may agree with one change and reject another. Narrow proposals also make later checks more reliable: the system can compare the approved fields with the fields presented for execution instead of trying to interpret a general endorsement.

Step 6: Review an illustrative location request

Consider this hypothetical example. A franchise location asks to change the price of one named service for a defined two-week period. The request identifies a current price, a proposed price, a local reason, and the affected location. HQ policy allows location-specific exceptions only within a defined boundary, but the submitted proposal does not state whether an existing promotion would also apply. The AI extracts the request and flags the missing interaction rather than assuming an answer.

The reviewer sees the current rule version, the exact price change, the requested dates, and the unanswered promotion question. The reviewer asks the location to clarify the interaction. The revised request receives a new version with the clarification attached. If the proposed price is inside the permitted boundary and the reviewer has authority for this class of exception, the reviewer may approve that exact version. If not, the request goes to the role that can decide the out-of-bound case.

The important detail is not whether this hypothetical request is approved. The process makes the decision explicit and reproducible: the location, service, current and proposed values, dates, applicable rule, missing information, and final decision all refer to the same version. A reviewer can also decline only the price adjustment without changing the underlying policy or authorizing future exceptions.

A poor workflow would approve a message that says use the lower local price for now, then let an automation infer which service and end date the sender meant. Even if the sender and reviewer had a shared understanding at the time, later staff could not reliably distinguish the intended exception from a broader price change. The safer design requires the action to match the reviewed fields exactly.

Step 7: Bind approval to the exact change and make it expire

An approval must come before execution and identify the exact payload it authorizes. At minimum, bind it to the request version, location scope, rule or item, old and new values, effective period, and approved action. If any material field changes, the approval no longer applies. This prevents a valid decision on a small change from being reused to justify a different one.

Store the decision-maker, decision time, decision, conditions, and approved payload alongside the request. Record a clear expiry rather than relying on someone to remember to reverse a temporary change. Expiry means the exception should stop being treated as active; it does not prove that a separate system has restored the standard value. The workflow should verify the actual state after the end date and raise a task if it differs from the intended baseline.

A useful approval screen presents the exact before-and-after values and the scope in a stable, readable form. The reviewer should be able to reject or request changes without editing the original request invisibly. If the proposal is edited, produce a new version and require a decision on that version. Approval must not be transferable from one location or price item to another just because the request wording is similar.

The controls described here are about the decision and its execution, not about a vendor’s feature set. Dayrun describes multi-location and approvals features on its site; evaluate those pages against your own acceptance tests rather than assuming a particular exception workflow is covered (multi-location; approvals).

Step 8: Execute only the approved payload and verify the result

Separate approval from execution. After approval, a controlled handoff should compare the proposed action with the approved payload, confirm the approval is still current, and reject mismatches. Only then should the responsible system or operator apply the change. The handoff should preserve the request identifier and approval record so a later review can trace what was authorized.

Do not treat a successful tool response or a model statement as proof that the business result occurred. Verify the relevant state independently: for a price, check the active value for the intended location and item; for a policy, check that the intended operating instruction is published or otherwise available to the people expected to follow it. Record both the execution event and the observed result. If the system cannot confirm the outcome, mark the request as unresolved rather than completed.

External actions can fail partway through. A request can time out after a destination has accepted a change, or a retry can apply an action twice if the destination does not protect against duplicates. Do not promise exactly-once effects. Use a stable request identifier where the destination supports it, inspect the destination state before retrying, and route uncertain cases to a person who can reconcile the intended and actual values.

If an action succeeds but the verification check fails, stop further automated changes for that request. Capture the last known state, the action attempted, the response received, and the discrepancy. The operator should decide whether to correct, reverse, or leave the change in place while investigating. A blind retry can turn a partial failure into a second, conflicting change.

Step 9: Expire, renew, or revoke exceptions deliberately

Every exception needs an end condition. For a time-bound change, schedule a check around the expiry and verify that the standard rule or price is active afterward. For a condition-based exception, define the observable event that ends it and who confirms that event. Avoid indefinite exceptions created by leaving the end date blank; they tend to become unofficial policy.

Renewal is a new decision, not an automatic continuation. Ask whether the original reason still holds, whether the observed result supports renewal, and whether the central rule has changed since approval. The renewal record should reference the prior exception but contain its own dates and approved payload. A reviewer should be able to decline renewal without rewriting the history of the original decision.

Revocation should be available when circumstances change or a problem is found. Record who initiated it, when it took effect, what state should replace the exception, and whether that state was verified. If a location has already acted on the exception, the business may need a separate operational response. This guide does not prescribe that response; it emphasizes that revoking permission in a workflow does not automatically undo an effect already produced elsewhere.

Measure the process by whether exceptions are bounded, reviewable, and correctly reflected in the operating state. Useful measures include the share of requests with complete fields at first submission, time spent waiting for missing information, approval-to-execution mismatches, unverified completions, and exceptions still active after expiry. Interpret these measures as diagnostic signals. A high approval rate, for instance, does not prove that the decision process is sound.

Step 10: Test the workflow before relying on it

Run acceptance tests using deliberately varied cases. Include an in-bound request with complete fields, an out-of-bound request, an expired approval, a revised payload after approval, an unavailable rule version, a missing end date, and an execution response that cannot be verified. The expected result should be written down before the test. These are proposed tests for an organization to run in its own environment; they are not claims that any particular product has passed them.

For each case, inspect the full path: what the requester entered, what the AI extracted, which rule version was compared, what the reviewer saw, what was approved, what the executor received, and what was verified afterward. A test that checks only the final screen can miss a dangerous mismatch between the displayed proposal and the executed values. Include a person who understands the local operation and one who owns the central rule.

A measurable acceptance criterion could be: in a defined test set of 20 requests, every change executed must match the approved location, item or rule, value, and validity period exactly; every expired, changed, or unapproved request must be held; and every completed request must have a recorded post-action verification. The number 20 is an illustrative test size, not a universal statistical threshold. Choose a sample that is meaningful for the range of cases your process will face, and assess failures by severity as well as count.

Test operational recovery too. Simulate a timeout after a change is sent, a stale policy record, a reviewer who asks for a correction, and a local request to expand scope after approval. Confirm that the workflow preserves evidence and routes each case without silently treating it as successful. If the process cannot distinguish applied from unverified, do not label both states complete.

An operational flow for controlled exceptions

The flow below shows the essential branch: a request either remains within an established HQ rule or becomes a bounded exception proposal. An exception proceeds only when approval is current and matches the proposed payload. Both the standard and exception paths still require an outcome check; a request that is not approved or has expired is held rather than executed.

flowchart TD
    accTitle: Franchise exception decision and execution
    accDescr: A request is checked against an HQ rule. Standard requests proceed to an action and result check. Out-of-rule requests need a bounded proposal and current matching approval. Unapproved or expired requests are held.
    A["Location request"] --> B{"Within HQ rule?"}
    B -- "Yes" --> C["Prepare standard action"]
    B -- "No" --> D["Prepare bounded exception"]
    C --> F["Execute and verify result"]
    D --> E{"Approved and current?"}
    E -- "Yes" --> F
    E -- "No" --> G["Hold and resolve"]

The decision at the first branch depends on a current, identifiable rule. If that rule is missing, the request should not be classified as within bounds by default. The approval branch checks both validity and payload match: a current approval for another location or an earlier version is not sufficient. After execution, verification compares the real operating state with the intended state, not with the AI’s prediction of what should have happened.

The hold branch is an operational outcome, not a dead end. It should identify the reason, such as missing information, an expired decision, or a mismatch, and specify who must resolve it. Where the source of uncertainty is a failed or indeterminate external action, preserve the evidence and investigate before retrying. This keeps uncertainty visible instead of converting it into an unsupported success status.

Compare exception handling approaches before choosing one

Different operating models suit different levels of local variation. The table compares common approaches by their practical tradeoffs. It is not a ranking of products; a business may combine approaches for different classes of rule.

Approach	Useful when	Advantages	Main tradeoff
HQ-only changes	Local variation is not permitted for the rule	Clear central control and fewer exception states to maintain	Local needs may wait for a central revision
Predefined local ranges	The business can define a safe, bounded range in advance	Routine in-range decisions can be handled consistently	The range must be explicit, current, and monitored
Case-by-case exception	Requests vary materially or have meaningful business consequences	A reviewer can assess the specific reason and scope	Review capacity and complete request records become important
Local discretion with later review	Decisions need to be made immediately and consequences are limited	Less delay for frontline operators	Retrospective review cannot prevent an unsuitable change already made

A predefined range is not automatically the best choice. It reduces repeated review only when the organization can describe the range precisely and reliably check that a request stays within it. If local conditions vary in ways the rule does not capture, a narrow case review may be safer than trying to encode every edge case into a broad permission.

HQ-only control is also not automatically superior. It can preserve consistency, but a central team that cannot respond within the time the business needs may encourage workarounds. The useful design question is whether the rule’s purpose can be protected while allowing a clearly limited local choice. If the answer is no, preserve the central rule and make the escalation path usable rather than creating a nominal exception that bypasses it.

Retrospective review should be reserved for a situation where the business has explicitly accepted the possibility that the action occurs before review. It is not a substitute for approval-before-execution when the change requires prior authorization. Be clear about the different risk: later detection may help correct a decision, but it cannot make the original action un-happen.

Failure patterns and what to change

A frequent design failure is treating a reason as authorization. A location may explain that a competitor has changed a price or that a local operating condition is unusual. That information can help a reviewer assess a request, but it does not itself establish that a change is allowed. The process needs a rule or a decision-maker with authority to consider an exception.

Another failure is using a broad approval that can be reinterpreted later. Phrases such as approved for the season or okay for local use leave open which locations, values, and dates are covered. Replace them with an exact, bounded payload. If the business cannot determine the exact payload at review time, keep the request in a proposal state and ask for clarification.

A stale rule can produce a technically consistent but business-wrong decision. A request may be compared against a copied policy that has since changed, or a local team may act on an old approved value. Keep rule versions and effective dates with requests, and define how new central rules affect existing exceptions. When that interaction is undecided, pause affected requests until the policy owner specifies it rather than letting each location infer the answer.

A final failure is declaring completion when only one stage succeeded. Approval may have been recorded while the update failed; an update may have been sent while its effect remains uncertain; or an exception may have expired in a database while the old value remains visible at the location. Use distinct statuses for decision, execution, verification, and expiry. That separation shows operators where the process actually stopped and what work remains.

If exception volume rises, do not respond by making approvals broader without diagnosing the pattern. Repeated requests may reveal that a central rule is out of date, a permitted range is too narrow, a form is unclear, or a local condition is recurring. Aggregate requests by rule and reason, then decide whether the underlying policy should change. A policy revision is a central decision; it should not emerge accidentally from repeated local exceptions.

Printable exception worksheet

Use this worksheet to review one proposed exception. It can be copied into an internal form or operating record. Blank fields are prompts for the business to define, not permission to assume a default. Keep the original request and the completed decision record linked.

• Request identity: Record a unique request identifier, requester, location, submission date, and the original request.
• Rule reference: Name the exact HQ rule or price item, its version, effective date, and the central owner.
• Current state: Record the current policy behavior or value, including units, currency, item, and location where applicable.
• Requested state: Write the exact proposed behavior or value. Identify every location and item in scope.
• Reason and evidence: Separate the requester’s explanation from supporting facts. Note what remains unverified.
• Boundary check: State whether the request is within an explicitly permitted range. If no range exists or the rule is unclear, hold for review.
• Timing: Record start and expiry, the relevant local-time convention, and what event ends the exception if expiry is conditional.
• Review decision: Capture approve, decline, or needs information; reviewer; time; conditions; and the exact request version reviewed.
• Payload match: Before execution, confirm that location, rule or item, current and proposed values, scope, and dates match the approved version.
• Execution evidence: Record who or what applied the change, when, the request identifier, and any response or error.
• Outcome verification: Check the actual policy or price state, record the observation and time, and mark unresolved discrepancies for human review.
• Expiry or renewal: Verify restoration of the standard state, or create a new request for a separately reviewed renewal.

A reviewer can use a simple decision record at the end: Decision: ___; approved request version: ___; authorized scope and values: ___; effective period: ___; conditions: ___; reviewer and time: ___; verification owner: ___. If the blank fields make the authorization ambiguous, it is not ready for execution.

Putting the process into operation

Pilot the workflow on a narrow group of rules and locations where the business can compare requests, decisions, and resulting state. Choose cases that exercise both routine and boundary paths. Review whether people can submit a complete request, whether the decision-maker sees the exact proposed change, and whether the outcome can be verified without relying on a model-generated summary alone.

Keep the AI’s role proportionate to the evidence available. Extracting fields and preparing a comparison can reduce repetitive reading, but uncertain policy interpretation should remain visible to a human. If the organization is planning an agent workflow, patterns for keeping people involved at consequential decision points are discussed in human oversight for production agents. For teams implementing the process across systems, operations automation may be a relevant next step.

Keep adjacent workflows distinct. Customer follow-up needs its own treatment of context and message handling, as described in a guide to customer follow-ups. Payment decisions require explicit authority boundaries; see guidance on deposits and refunds. Staffing decisions also have different human-control needs, covered in a guide to sick-day roster gaps. Reusing the same exception workflow for those decisions without examining their distinct consequences would blur the scope this process is designed to control.

Pro tip: Review declined, delayed, expired, and failed requests as well as approved ones. Those records often reveal unclear boundaries or execution gaps that an approval-rate dashboard would miss.

Summary: keep local flexibility explicit

A dependable franchise exception process starts by separating the HQ rule from the local variation it may permit. It records requests in structured fields, compares them against a current rule, and presents a bounded proposal for review. Approval comes before execution, applies to the exact payload, and expires. The process then verifies the business state independently and preserves uncertainty when an external action cannot be confirmed.

The practical test is straightforward: can an operator identify what changed, where it changed, who authorized it, for which period, and whether the intended result actually occurred? If the answer depends on interpreting a chat message or trusting a model’s confident summary, tighten the request record and decision boundary before expanding automation. Local discretion is most useful when its limits are visible, reviewable, and easy to restore.