What manager approval should look like

“Human in the loop” is one of the easiest claims for software to make and one of the hardest to verify. A person can be shown a conclusion, given one bright button, and still have no meaningful control over the decision.

In a restaurant, approval has operational consequences. A price, prep target, count adjustment, purchasing decision, or service-window action can affect guests, staff, inventory, cash, and the systems that run the business. The manager should not become a ceremonial checkpoint for an answer they cannot inspect.

Approval begins with authority.

The person reviewing the recommendation must have the restaurant role and location authority to make that decision. Being logged in is not enough. The product should load the person’s permissions from the restaurant’s authorized records, identify the location and decision type, and refuse the action when authority is missing or stale.

Authority also has a time dimension. A manager who changed locations, left the business, or lost responsibility for a policy should not retain silent approval power because an old session still exists.

The manager needs the case, not just the answer.

Before deciding, the manager should see what changed, which records support it, when those records were observed, who reviewed them, which rule was applied, what remains estimated, and what the recommendation cannot do.

For a cost-related recommendation, that may include the invoice line, vendor item, ingredient, recipe version, inventory context, current price, proposed review, service window, quantity cap, configured floor, source freshness, and missing records.

A confidence percentage without that context is not a substitute. It may look precise while leaving the manager unable to identify the part of the case that is uncertain.

The options must be real.

Approve, edit, reject, and ignore are different operating choices. Each needs to be available when appropriate, and each needs to be honored.

• Approve records the recommendation and its limits as the manager’s current decision.
• Edit records the manager’s changed values, reason, and a new revision rather than overwriting the original recommendation.
• Reject records that the recommendation should not proceed and may include a reason the product did not capture.
• Ignore leaves the issue undecided without manufacturing a rejection or success.

The interface should not punish rejection, hide the edit path, preselect approval, or use wording that makes “no” feel like an error. A manager decision is only meaningful when the alternative is available.

Approval and execution are separate.

A manager can agree with a recommendation without granting software permission to change an external system. The product should say exactly what the button does before the manager presses it.

In the Dynamic.ly workflow described on this site, approval records an internal decision. It does not change a point-of-sale menu, publish an offer, update an inventory record, create an order, move money, or contact a customer. When the restaurant chooses to act, it uses its own authorized process and verifies the change separately.

This separation is not a temporary disclaimer. It is an authority boundary. A future execution capability would require a separate product, permission, legal, safety, readback, rollback, and manager-authorization decision.

The record must survive the screen.

After the manager decides, the product should retain the source references, recommendation revision, selected option, edits, actor, role, location, time, limits, and evidence state. A later change should create history rather than rewrite it.

Failures remain in the record too. If a source refresh fails, a mapping changes, or a later measurement is unavailable, the system should not preserve the appearance of a clean success while dropping the evidence that complicates it.

Rejection is information, not automatic training data.

A manager may reject a recommendation because of a private event, a staffing concern, a guest expectation, a supplier issue, a brand rule, or simple disagreement. That reason can improve the next review only if the restaurant chooses to provide it and the product records how it was used.

The system should not silently convert one manager’s decision into a universal rule, change weights across restaurants, or teach itself that rejection always means the underlying evidence was wrong. Restaurant context and model learning are separate problems.

Measurement comes after the decision.

A decision record proves that the manager chose an option. It does not prove that the restaurant carried it out or that the projected result occurred. Those questions require separate observation, a defined window, a baseline, and the records that can support the outcome.

Estimated impact and measured outcome should remain separate even when the result is favorable. Trust does not come from always being right. It comes from making the difference visible when the recommendation and reality do not match.

A practical approval standard

• The reviewer has current authority for the location and decision.
• The source and review state are inspectable.
• The calculation, estimate, and missing information are distinguished.
• The recommendation includes its item, window, cap, floor, and stop conditions.
• Approve, edit, reject, and ignore are meaningful choices.
• The interface states whether an external action will occur.
• The decision creates a durable revision and audit record.
• A later result is measured separately.

A useful recommendation remains optional, legible, and accountable. The manager keeps the decision because the manager keeps the responsibility.