Human In The Loop

Les humains de la boucle sont des users

Tous ceux qui approuvent ou soumettent sont des users de la station : des clients en product, des employés en process. Un admin n'approuve jamais une action métier : il ne voit, à l'exécution, que les incidents (action.failed, delivery.failed, policy.disputed), qu'il traite dans la console.

who	le user	comment on l'atteint
owner	le propriétaire de la room	dans la room, sur son portail
principal	la personne qui a envoyé l'agent	par l'agent lui-même : il demande à son user de confirmer (confirmation MCP, lien)
user.approver	l'autorité au-dessus du user	product : l'approbateur que l'organisation cliente a fixé sur la sous-identité, sur le canal qu'elle a déclaré ; process : son manager dans l'annuaire
{role: x}	un rôle que la station désigne : la finance, l'IT	une boîte de la station

user.approver est le même concept dans les deux kinds : le responsable de bureau de Cabinet Diallo et le manager d'un employé du support approuvent au-dessus du user. Seule la source change.

    submitted_by:
      - {who: agent, when: "total <= 50 and agent.mode == 'autonomous'"}
      - {who: user.approver, when: "total > identity.limits.max_amount"}
      - {who: {role: finance}, when: "total > 1000"}
      - {who: owner}

Les couches s'additionnent et la plus stricte gagne : une commande au-dessus du plafond de la sous-identité et du seuil de la station est approuvée par les deux, chacun pour ce qu'il protège.

À qui appartient la room

Le propriétaire est toujours un user : le client qui ouvre une session, ou — quand un événement ou une automatisation ouvre la room — le rôle que la config nomme. La personne dont il s'agit n'en est pas propriétaire : le client d'un ticket est concerné (concerns). On peut le prévenir, ses données sont protégées ; il n'agit sur rien.

      room: {key: "$event.ticket_id", owner: {role: support}, concerns: "$event.requester"}

owner: {role: support} veut dire « l'employé du support qui le prend » : chacun rejoint la room avec sa propre identité, et le journal dit qui a fait quoi.

Où arrive une décision d'un rôle

Quand une politique demande un rôle, l'action passe en attente dans la boîte de ce rôle.

inboxes:
  support-manager: {channel: teams, deadline: 4h, escalate_to: head-of-support}
  it:              {channel: teams, deadline: 1d, escalate_to: it-lead}
  rh:              {channel: console, deadline: 2d}

Une boîte n'est pas un portail : c'est la station qui appelle un user à décider.

L'approbateur voit l'action finale (l'approbation est la dernière garde, après le prix), les lectures sur lesquelles elle repose, et — quand une politique smart a demandé son avis — pourquoi.

Les relances sont des automatisations sur approval.requested, avec older_than.

Expliquer et contester

Chaque refus et chaque « un humain doit décider » porte une raison qu'une personne peut lire. Une décision qui touche une personne et fait intervenir un modèle a un recours humain.

Séparer les rôles

Les règles peuvent citer les autres acteurs du parcours :

      - {approval: {role: support-manager, not: "$run.requester"}}

Par défaut, l'approbateur est différent du demandeur. Un manager qui demande son propre remboursement passe par un autre manager.

Réserver et soumettre : deux personnes

Une écriture peut être réservée par un user et soumise par un autre. À l'arrivée d'un salarié, les RH réservent la création du compte ; seule l'IT peut la soumettre :

    submit_guard:
      submitted_by:
        - {who: {role: it}, when: "any(skill == 'create-workspace-account')"}
        - {who: {role: rh}}