Approve to run: how an AI proposal becomes a governed action

The shape of the pattern

Approve to run is a division of labour. The model reads what it is allowed to read, writes a proposal in words, and hands it to a person. That person opens it inside the tool that owns the action, sees what it would do, and signs. The signature is what runs. Take the person out of the middle and the proposal stays a paragraph on a screen.

The order matters more than it looks. In an agentic design the model acts and a person reviews later, if at all. Here the trigger belongs to the person. That makes the review the only route to the action, not a safety net somebody can be too busy to check.

A proposal waits for a person. Each one becomes a card the reader opens and approves in the tool’s own gate.

Advice and action differ

An assistant that acts and an assistant that advises are sold with the same words. They are different purchases. The difference shows up in the questions your risk function asks, and again on a bad day.

• The failure mode. When an advisory model gets something wrong, a person reads a wrong sentence. When an acting model gets something wrong, a change lands in your environment and somebody finds it later.
• The accountable name. An approval carries the name of the person who gave it. An action taken by a service identity carries the name of the service, which answers a question nobody asked.
• The moment of review. Advice is reviewed while it is still cheap. An action is reviewed after the fact, in a log, beside everything else that happened that week.

Both designs have their place. Inside a governed Tableau environment, the advisory one is what gets signed off. A single published data source can sit under a hundred workbooks, and one permission change reaches every one of them.

Where the action list lives

A proposal is only as bounded as the list it comes from. Each tool declares its own list of proposable actions on the server. The model picks from that list by name, and adds one block of action ids at the end of its answer.

• The model picks which action, never the address. The server builds the deep link from the tool’s own registered prefix, so a link can lead only where that tool already lives.
• Anything outside the list is dropped. An id the registry does not hold, a repeat of one already proposed, or a malformed block is discarded before the answer reaches the screen.
• A read-only tool proposes reads. Where a tool scans, maps or extracts and writes nothing back to Tableau, its registry entry says exactly that, and reads are all it can put forward.

That is the practical value of a list you can read end to end. A reviewer who wants every change this assistant could ever suggest reads one registry, in one file, in an afternoon. An instruction telling a model to behave itself leaves that reviewer with nothing to read.

What an approval records

An approval that records only that somebody clicked yes is a click. Five fields separate a gate from a dialog box.

Who approved

A named person, taken from the live session at the moment of approval. A role or a shared account is weaker on every count.

What exactly

The exact item and the exact change. A reader a year later should be able to rebuild the decision from the record alone.

Against what evidence

The report, scan or check the approver was looking at. An approval cut loose from its evidence is an opinion with a timestamp.

When, and in what order

A time, and a place in a sequence. A later reader can then tell whether the approval came before the change or after it.

What a repeat does

Whether running the same approval twice does the work twice. Several gates here are idempotent, meaning a repeat settles the state instead of duplicating it, and they say so on the gate.

The last field is the one people forget. A gate that quietly does the work again on a second submission turns a nervous double click into a second change. The audit then shows two approvals for one intended action.

What the gates ask for

Every registered action names the gate behind it. A proposal card can then tell the reader what they will be asked for before they open it. These are the registry’s own summaries.

Publishing a workbook

A dual signature and a quality gate. It writes a new copy only, and the publish is audited.

Promoting a report to production

A pass-only rule and a binding signature. Idempotent, so a repeat approval settles without duplicating.

Approving a migration

An approver name and a reviewed-risk confirmation. Idempotent.

Removing a leaver’s access

A role gate and an explicit acknowledgement of the credentials embedded in that person’s content. Idempotent.

Enabling an automation

A dual-control acknowledgement and a clean review before the automation may be turned on at all.

Read the table as a whole and the pattern is the argument. Two signatures where content is published. A named approver where a migration runs. An acknowledgement where credentials are embedded. The weight of the gate follows the weight of the action, rather than sitting at one setting for everything.

Spotting a real gate

1. Ask what executes. If approving sets a flag that a background job reads later, the approval and the action are two events, and something can happen in the gap.
2. Ask what the record holds. Read one real approval row. If it names a person, an item and the evidence, it is a control. If it names a session id and a time, it is telemetry.
3. Ask what a second click does. Submit the same approval twice in a test environment, and watch whether the work happens twice.
4. Ask where the list of possible actions lives. A list you can read off the server is a list you can review. A list that lives inside a prompt is a hope.

One person on your own team can answer all four inside your own environment. No figure quoted in a data sheet tells you that much.