Jarvisby TheSEO
EN
Language · same pageNLNederlands/jarvis/kennis/menselijke-goedkeuring/ENEnglish (UK)/en/jarvis/knowledge/human-approval/ESEspañolnot translated yetWe do not remember your choice and never redirect you automatically.
ARCH · human approvalgovernance in code · 28 July 2026

An approval is more than a button.

A person only really holds control when the system knows who approved which version for what, and which consequence is allowed to follow.

Next: super brain and client brains →The logging protocolnot every approval carries the same weight
FIG.G01: Not every approval carries the same weightGOV · policy per action type

Four actions, ordered by what they can do

Four actions, ordered by what they can do. Saving an internal draft is a different thing from signing a contract, and the weight of the approval should move with it. The bar shows that order and no scale, because a number here would suggest more precision than there is. Which extra requirements can apply at higher impact stands separately below, because that link is settled per organisation.

~/jarvis/knowledge/human-approval · risk.levels[note] no scale
four actions from this pagerising impact, no scale
what can be added at higher impacttwo approvalsa waiting periodre-authentication
# the four actions and the three heavier requirements are in the paragraph about risk levels; which requirement belongs to which action is policy and is agreed per organisation, so that link is deliberately left blank here

The appearance of control

Plenty of AI interfaces put an Approve button next to a text field. That feels safe, but it is worthless if the content can still change after approval, if any user is allowed to click, or if the button fires several actions at once with no visible consequence.

Five properties

  1. Exact version: the approval points at an immutable version of the content.
  2. Authorisation: the server checks role, tenant and task scope.
  3. Deliberate intent: the user sees the action, the destination and the risk before agreeing.
  4. Idempotent consequence: the same approval cannot accidentally cause two emails or two payments.
  5. Audit and revocation: timestamp, actor, reason and any revocation are recorded.

Different levels of risk

Saving an internal draft is a different thing from emailing a quote, changing a contract or activating knowledge organisation wide. Jarvis should apply policy per action type. Higher impact can call for two approvals, a waiting period or re-authentication. How that human control relates to the EU AI Act, and why the legal role is decided per use case, is at the AI Act position for Jarvis.

No approval fatigue

If every small step asks for a pop-up, people start clicking blind. The answer is not less governance but better bundling: show only the decisions with a real consequence, record the low risk steps up front as policy, and let the exceptions come forward.

In the current interface

The local preview already shows that a draft can be approved, that a knowledge update is assessed separately and that the payment gate stays blocked until legal permission has been given. For production, server side version checks, authorisation, audit events and webhook idempotency have to enforce this behaviour.

Section · Next stepreachable 24/7
Book a call ↗