suissAI

Posted on Feb 26

FullAgenticStack WhatsApp-first: RFC-WF-0022

#webdev #programming #rfc #whatsappf

RFC-WF-0022

Human-in-the-Loop Profiles & Approval Flows (HAPF)

Status: Draft Standard
Version: 1.0.0
Date: 20 Nov 2025
Category: Standards Track
Author: FullAgenticStack Initiative
Dependencies: RFC-WF-0003 (CCP), RFC-WF-0004 (ACSM), RFC-WF-0005 (CRCD), RFC-WF-0006 (EAS), RFC-WF-0008 (RCP), RFC-WF-0015 (PPGP), RFC-WF-0018 (SMCL), RFC-WF-0020 (RAOS)
License: Open Specification (Public, Royalty-Free)

Abstract

This document specifies Human-in-the-Loop Profiles & Approval Flows (HAPF) for WhatsApp-first systems. HAPF defines normative requirements for approval gating of state mutations—especially destructive, administrative, and high-impact recovery actions—using structured approval flows over WhatsApp. HAPF standardizes approval roles, approval policies, multi-approver modes (optional), binding of approvals to command envelopes, evidence emission for approvals, timeout/expiry rules, and safe escalation behaviors.

Index Terms— human-in-the-loop, approvals, step-up verification, destructive actions, administrative controls, governance, conversational operations.

I. Introduction

CCP mandates explicit confirmations for state mutations; ACSM mandates step-up for high-impact actions. In practice, systems often require an additional governance layer: approvals (HITL) where a human (or multiple humans) explicitly authorizes execution beyond mere confirmation—especially when agents propose actions or when the blast radius is large (billing, access, recovery).

HAPF defines approval flows that remain WhatsApp-first: no mandatory dashboard approvals.

II. Scope

HAPF specifies:

Approval policy model and profiles (basic/strong/operational)
Approval roles (requester, approver, observer)
Approval flow states and lifecycle integration (SMCL)
Approval binding to CCP envelopes and IDS replay safety
Optional multi-approver (“2-person rule”) modes
Evidence requirements for approvals (EAS)
Expiry, cancellation, and escalation rules
Rate limits and abuse protections for approval requests (RAOS)

HAPF does not mandate organization charts; it defines protocol obligations.

III. Normative Language

MUST, MUST NOT, SHOULD, SHOULD NOT, MAY are normative.

IV. Definitions

Confirmation: A requester’s explicit acknowledgment of an action (CCP).
Approval: A governance decision by an authorized approver distinct from the requester (or, in some profiles, the same person under stronger step-up).
Requester: Actor initiating the command.
Approver: Actor authorized to approve execution under an approval policy.
Approval Token: A short-lived token binding an approval decision to a command envelope.
Approval Policy: Rules deciding which commands require approvals and what kind.

V. Design Goals

HAPF MUST ensure:

G1. Safety: prevent high-impact actions without explicit human approval.
G2. WhatsApp-first: approvals occur via WhatsApp, not dashboards.
G3. Binding: approvals are cryptographically/structurally bound to a specific command envelope.
G4. Auditability: approvals emit evidence artifacts and can be inspected via OoC.
G5. Replay Safety: duplicates cannot cause repeated approvals or bypass approvals.
G6. Usability: approval requests are concise and preview-first.

VI. Approval Requirement Model

A. When Approvals Are Required (Minimum)

Systems MUST support policies that require approvals for at least:

S2 (Destructive) commands (cancel/delete/revoke/reset-like)
S3 (Admin High-Impact) commands (scopes, secrets, billing, global policies)
R3 recovery actions (compensate/reset/bulk recovery)

Systems MAY extend approval requirements to other domains.

B. Approval Profiles

Implementations MUST support at least:

HAPF-Basic: approvals required for S3 and R3; optional for S2
HAPF-Strong: approvals required for S2, S3, and R3
HAPF-Operational: Strong + optional 2-person rule for configured domains

Profiles SHOULD be distributed and bound via policy packs (PPGP).

VII. Roles and Authorization

A. Role Separation

In Strong and Operational profiles, the approver SHOULD be different from the requester for S3/R3 actions.

B. Approver Authorization

Approvers MUST be authorized via ACSM scopes, e.g.:

admin.approve.destructive
admin.approve.high_impact
admin.approve.recovery

Approval scopes MUST be auditable and step-up protected.

C. Delegation (Optional)

If delegation exists, approvals MUST record delegation context and MUST be revocable.

VIII. Approval Flow Lifecycle (SMCL Integration)

Approval adds additional states between authorized and started for impacted commands.

A. Approval States (Normative)

For commands requiring approval, the lifecycle MUST include:

approval_required
approval_requested
approval_granted OR approval_denied (terminal for approval)
if denied → command transitions to rejected with reason approval_denied

B. Allowed Ordering

For approval-required commands, started MUST NOT occur unless:

confirmation satisfied (if required)
authorization granted
approval granted (HAPF)

IX. Approval Request Content (Preview-First)

An approval request MUST include:

command summary (entity/action/target)
requester identity
risk label (S2/S3/R3)
impact preview (what changes, what is affected)
expiry time
approve/deny options (numbered + explicit token/phrase)

Example structure (normative fields, not wording):

1 — Approve (token ABC1)
2 — Deny

Approvals MUST NOT require a web UI.

X. Binding and Replay Safety

A. Envelope Binding

Approval decisions MUST bind to:

command_id
idempotency_key
normalized intent/target fingerprint (recommended)

B. Single-Use Approval Tokens

Approval tokens MUST be:

short-lived
single-use
envelope-bound

C. Duplicate Handling

If an approval response is duplicated, the system MUST replay the already-recorded approval decision and MUST NOT create multiple approvals.

XI. Multi-Approver Modes (Optional)

If 2-person rule is enabled, the system MUST define:

required count (e.g., 2 approvals)
quorum logic
who can approve (distinct approvers)
expiry behavior if quorum not met
evidence records per approver

Quorum-based approvals MUST remain WhatsApp-operable.

XII. Evidence Requirements (EAS)

Approvals MUST emit evidence artifacts that allow auditing:

approval requested (who requested, to whom, when, expiry)
approval granted/denied (who decided, method, timestamp)
binding references to command envelope
policy/profile identifiers used

These MAY be expressed as observation.emitted extensions or a standardized approval.* artifact set if later added; for v1.0.0 they MUST be representable within EAS using permitted extension rules (SECR).

XIII. Timeouts, Cancellation, and Escalation

A. Expiry

Approval requests MUST expire after a policy-defined duration.

If expired:

command MUST NOT execute
command SHOULD transition to rejected with reason approval_expired OR remain in a blocked state awaiting re-request (policy-defined)

B. Cancellation

Requesters with sufficient scope MAY cancel an approval request prior to grant; cancellation MUST emit evidence.

C. Escalation

Systems MAY escalate approval requests to a fallback approver group, but escalation MUST be scope-gated and evidence-backed.

XIV. Abuse Controls (RAOS Alignment)

Approval requests and responses MUST be rate-limited:

prevent spamming approvers
prevent brute-forcing approval tokens
prevent repeated deny loops

Under suspicious behavior, the system SHOULD degrade to stricter approval requirements or temporarily suspend approval requests.

XV. Binding to CRCD and PPGP

Commands that require approvals MUST declare in CRCD:

approval_policy_id (or equivalent binding)
risk class and recommended profile

Approval policies SHOULD be distributed via policy packs (PPGP), including:

which safety classes require approval
approver scope requirements
expiry timeouts
multi-approver quorum rules (if enabled)

XVI. Relationship to Other RFCs

CCP (0003): confirmations and canonical envelopes.
ACSM (0004): scopes and step-up authorization for approvers.
CRCD (0005): command declarations and policy bindings.
EAS (0006): evidence recording for approvals.
RCP (0008): approvals for high-impact recovery actions.
PPGP (0015): distribution and binding of approval policies/profiles.
SMCL (0018): lifecycle state integration and ordering constraints.
RAOS (0020): rate limits and abuse protections for approvals.

XVII. Security Considerations

Approvals reduce risk but can be attacked (token brute force, approver phishing, spam). Implementations MUST protect approval tokens, enforce step-up for approvers, and audit all approval decisions. Multi-approver modes can reduce single-point compromise but add operational complexity; policies must balance both.

XVIII. Conclusion

HAPF turns “human confirmation” into a formal, auditable governance layer for WhatsApp-first systems—especially for destructive/admin/recovery actions and agent-proposed operations. By standardizing profiles, approval states, binding, expiry, and evidence, HAPF strengthens safety without breaking WhatsApp-first operability.

References

[1] RFC-WF-0003, Conversational Command Protocol (CCP).
[2] RFC-WF-0004, Administrative Command Security Model (ACSM).
[3] RFC-WF-0005, Command Registry & Capability Declaration (CRCD).
[4] RFC-WF-0006, Evidence Artifact Schema (EAS).
[5] RFC-WF-0008, Recovery & Compensation Protocol (RCP).
[6] RFC-WF-0015, Policy Packs & Governance Profiles (PPGP).
[7] RFC-WF-0018, State Model & Command Lifecycle (SMCL).
[8] RFC-WF-0020, Rate Limits, Abuse Controls & Operational Safety (RAOS).

Concepts and Technologies

Human-in-the-loop governance, approval policies, envelope-bound approval tokens, quorum approvals (2-person rule), approval lifecycle states, evidence-backed approvals, expiry/cancellation/escalation, approval spam prevention, step-up for approvers.

DEV Community