DEV Community

Cover image for FullAgenticStack WhatsApp-first: RFC-WF-0023
suissAI
suissAI

Posted on

FullAgenticStack WhatsApp-first: RFC-WF-0023

#webdev #programming #rfc #whatsapp

RFC-WF-0023

Template UX Patterns for Conversational Ops (TUXP)

Status: Draft Standard
Version: 1.0.0
Date: 20 Nov 2025
Category: Standards Track
Author: FullAgenticStack Initiative
Dependencies: RFC-WF-0002 (WWCS), RFC-WF-0003 (CCP), RFC-WF-0005 (CRCD), RFC-WF-0007 (OoC), RFC-WF-0008 (RCP), RFC-WF-0015 (PPGP), RFC-WF-0018 (SMCL)
License: Open Specification (Public, Royalty-Free)

Abstract

This document specifies Template UX Patterns for Conversational Ops (TUXP) for WhatsApp-first systems. TUXP defines a set of normative response and interaction templates to ensure consistent, safe, and efficient conversational operations across command execution, disambiguation, confirmation, observability drill-down, and recovery workflows. TUXP standardizes message structures (summary-first), numbered actions, preview blocks, error/denial explanations, and progressive disclosure patterns, enabling consistent UX across implementations while preserving protocol correctness.

Index Terms— conversational UX, templates, drill-down, disambiguation, confirmations, recovery flows, WhatsApp-first.

I. Introduction

Even with correct protocols (CCP/ACSM/IDS/EAS), WhatsApp-first systems can fail UX-wise: ambiguous prompts, missing previews, inconsistent menus, and verbose dumps that break operator workflow. TUXP provides standardized templates that:

  • reduce ambiguity and accidental execution
  • improve learnability (consistent patterns)
  • enable tooling to generate predictable conversational UI
  • align with WWCS conversion patterns (web → WhatsApp)

TUXP is not about branding tone; it’s about operational clarity and safety.

II. Scope

TUXP specifies:

  • Required template set and when each MUST be used
  • Formatting rules (summary-first, numbered actions, stable identifiers)
  • Disambiguation patterns for ambiguous intents/targets
  • Confirmation/approval preview structures
  • OoC drill-down patterns for evidence and errors
  • Recovery flow patterns (RCP options and execution)
  • Policy-driven verbosity and redaction constraints (PPGP)

TUXP does not define WhatsApp UI widgets; it defines textual structures compatible with WhatsApp constraints.

III. Normative Language

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

IV. Definitions

Template: A structured response pattern with required fields.
Summary-first: A response that begins with the minimum actionable summary before details.
Drill-down: Progressive disclosure via numbered choices or explicit follow-up commands.
Stable Identifier: A reference token like command_id, correlation_id, or resource id.

V. Design Goals

TUXP MUST ensure:

  • G1. Safety: reduce accidental destructive actions.
  • G2. Consistency: same situation → same response structure.
  • G3. Efficiency: minimal text overhead; drill-down for details.
  • G4. Traceability: include stable identifiers for follow-ups.
  • G5. Policy Compliance: obey redaction/detail policies.

VI. Core Formatting Rules (Normative)

A. Summary-First Rule

Any response about a command or system state MUST start with:

  1. what happened / what will happen
  2. the key identifier(s)
  3. next available actions (if any)

B. Numbered Action Rule

Whenever multiple actions are possible, the system MUST present options as:

  • 1 - <action>
  • 2 - <action>
  • …

Options MUST be stable for the current context.

C. Preview Block Rule

Before executing any mutation requiring confirmation/approval, the system MUST show a preview block containing:

  • entity + action + target id
  • impact summary
  • reversibility / recovery hint (if applicable)
  • required confirmation method (token/phrase)

D. Identifier Rule

Responses SHOULD include command_id (or a reference) when applicable, enabling OoC/RCP follow-ups.

E. Redaction Rule

Sensitive fields MUST be masked/dropped according to policy; templates MUST not “accidentally print” secrets or full PII.

VII. Required Template Set

T1 — Command Acknowledgement (Post-Canonicalization)

When: after CCP envelope creation (canonicalized).
MUST include: command_id, summary, next step (confirm/authz).

Structure (normative fields):

  • Summary line
  • command_id line
  • Next step line (confirm required? waiting authorization?)

T2 — Disambiguation List

When: ambiguous target/intent.
MUST include: numbered candidates with stable ids.

Structure:

  • “Ambiguity detected” summary
  • Candidate list with ids
  • Instruction: “reply with number” (or explicit id)

T3 — Confirmation Request (Mutation)

When: mutating S1 commands.
MUST include: preview block + confirmation instruction.

Structure:

  • Preview block
  • Confirmation method (explicit phrase or yes/no per policy)
  • Cancel option

T4 — Strengthened Confirmation (Destructive)

When: S2 destructive commands.
MUST include: preview + token/phrase binding + expiry.

Structure:

  • Preview block
  • “Confirm with TOKEN/PHRASE bound to target”
  • Expiry time
  • “Deny/Cancel” option

T5 — Approval Request (HITL)

When: approvals required (HAPF).
MUST include: requester, risk class, preview, approve/deny choices, expiry.

T6 — Execution Result

When: command reaches terminal (executed|rejected|failed|canceled|compensated).
MUST include: status, summary, affected resources (if non-sensitive), next actions.

T7 — Denial / Rejection Explanation

When: rejected by policy/authz/ambiguity.
MUST include: reason category and minimal remediation (“missing scope”, “needs approval”, “choose target”).

T8 — OoC Status Summary

When: OoC status queries.
MUST include: summary, lifecycle state, last error (if any), drill-down options.

T9 — Evidence Drill-down

When: user requests evidence.
MUST include: list of artifacts (types + timestamps), with numbered drill-down to view a specific artifact (redacted).

T10 — Recovery Options (RCP.OPTIONS)

When: a command is failed/blocked/partially executed.
MUST include: current state, why recoverable, numbered list of recovery actions with risk labels.

T11 — Recovery Execution Preview

When: user selects retry/reprocess/compensate.
MUST include: target command id, risk, expected effect, confirmation/approval method required.

VIII. Policy-Driven Variations (PPGP Integration)

Templates MUST be parameterized by governance policies, including:

  • max detail level (OoC)
  • redaction strategy
  • confirmation/approval method
  • verbosity caps under RAOS degradation modes

Implementations MUST be able to switch profiles without breaking template structure.

IX. Lifecycle Alignment (SMCL)

Templates SHOULD align with lifecycle stages:

  • canonicalized → T1
  • confirmation_required → T3/T4
  • approval_required → T5
  • started → short progress update (optional)
  • terminal states → T6/T7
  • OoC queries → T8/T9
  • recovery flows → T10/T11

X. Conformance Requirements

An implementation is TUXP-compliant if:

  1. it uses numbered actions for multi-choice interactions
  2. it shows preview blocks before mutating executions requiring confirmation/approval
  3. it uses disambiguation lists when needed
  4. it presents OoC and RCP outputs summary-first with drill-down
  5. it respects redaction/detail policies in all templates

XI. Security Considerations

Bad UX is a security vulnerability in conversational systems: ambiguous confirmations and verbose leakage cause real harm. Templates MUST be designed to prevent “accidental admin” and “leaky observability” scenarios. Under abuse conditions, systems SHOULD degrade to safer templates (summary-only, stricter confirmation).

XII. Conclusion

TUXP standardizes the conversational “operational UI kit” for WhatsApp-first: predictable templates for execution, safety, observability, and recovery. This reduces ambiguity, increases safety, and enables tooling to generate consistent conversational experiences across systems—without sacrificing protocol rigor.

References

[1] RFC-WF-0002, Web-to-WhatsApp Conversion Standard (WWCS).
[2] RFC-WF-0003, Conversational Command Protocol (CCP).
[3] RFC-WF-0005, Command Registry & Capability Declaration (CRCD).
[4] RFC-WF-0007, Observability over Conversation (OoC).
[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).

Concepts and Technologies

Summary-first UX, numbered action menus, disambiguation lists, preview blocks, strengthened confirmations, approval prompts, evidence drill-down, recovery option menus, policy-driven verbosity/redaction, lifecycle-aligned conversational UI patterns.

Top comments (0)