FullAgenticStack WhatsApp-first: RFC-WF-0005

RFC-WF-0005

Command Registry & Capability Declaration (CRCD)

Status: Draft Standard
Version: 1.0.0
Date: 20 Nov 2025
Category: Standards Track
Author: FullAgenticStack Initiative
Dependencies: RFC-WF-0001 (WFCS), RFC-WF-0002 (WWCS), RFC-WF-0003 (CCP), RFC-WF-0004 (ACSM)
License: Open Specification (Public, Royalty-Free)

---

Abstract

This document specifies the Command Registry & Capability Declaration (CRCD) standard for WhatsApp-first systems. CRCD defines a canonical, machine-readable registry of capabilities and their associated commands, including intent mappings, argument schemas, safety classification, authorization scopes, confirmation policies, multimodal constraints, and web→WhatsApp conversion hooks. The registry is the normative source of truth for determining whether a system satisfies WhatsApp-first parity, governance, and operational audit requirements.

Index Terms— capability registry, command schema, intent mapping, authorization scopes, confirmation policy, governance, WhatsApp-first compliance.

---

I. Introduction

WhatsApp-first compliance requires that all capabilities (domain + admin + recovery + observability) be conversationally executable. This cannot be reliably audited or automated if capabilities are implicit in code and scattered across services. CRCD standardizes a single canonical registry that declares:

• what the system can do (capabilities)
• how users invoke it (commands / intents)
• how it is secured (scopes, step-up)
• how it is executed safely (confirmation, idempotency class)
• how it is presented conversationally (menus, prompts, forms-as-flow patterns)

CRCD enables automation: compliance checks, menu generation, help/assist UX, and audit tooling.

---

II. Scope

CRCD specifies:

• the registry structure and required fields
• capability and command declaration rules
• mapping from conversational intents to executable commands
• argument schemas, validation rules, and normalization
• safety classification and confirmation policy binding
• authorization scope binding (ACSM integration)
• conversion hooks for WWCS (web UI patterns)
• versioning and deprecation rules
• minimum compliance checks derived from the registry

CRCD does not mandate a specific language, database, or schema engine. It defines normative field requirements and semantics.

---

III. Normative Language

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

---

IV. Definitions

Capability: Any feature that produces value or alters state (WFCS).
Command: An executable operation expressed conversationally and canonicalized into an envelope (CCP).
Registry: A machine-readable catalog of declared capabilities and commands (this RFC).
Intent Mapping: The mapping between NL/menus and canonical entity/action/target intent.
Safety Class: A classification that dictates confirmation and step-up requirements.

---

V. Design Goals

A CRCD-compliant system MUST provide:

• G1. Single Source of Truth: One canonical registry for all capabilities and commands.
• G2. Auditability: Registry is versioned and traceable (who changed what and when).
• G3. Automated UX: Menus, help, and disambiguation lists can be generated from the registry.
• G4. Security Binding: Each command is bound to scopes and step-up policies (ACSM).
• G5. Safety Binding: Each command is bound to confirmation policy and safety class (CCP).
• G6. Parity Verification: Registry supports verifying WhatsApp-first parity coverage (WFCS).

---

VI. Registry Structure

The system MUST publish a CRCD registry document (or API endpoint) that contains at minimum:

• registry_id
• system_id
• version (SemVer)
• generated_at
• capabilities[]
• commands[]
• scopes[] (or references to an external scope registry, still resolvable)
• policies[] (confirmation/step-up policies; may reference ACP/CCP/ACSM profiles)
• deprecations[] (optional)

The registry MUST be machine-readable (JSON or YAML).

---

VII. Capability Declaration

A. Required Fields

Each capability MUST declare:

• capability_id (stable unique identifier)
• name (human-readable)
• domain (e.g., Orders, Inventory, Billing, Admin)
• description
• critical_path (boolean)
• whatsapp_executable (boolean; MUST be true for WhatsApp-first systems)
• multimodal_supported (text/audio/doc/image flags, per WFCS)
• mutates_state (boolean)
• related_commands[] (references)

B. Parity Requirement

For WhatsApp-first compliance, every capability MUST have:

• whatsapp_executable = true
• at least one related command declared in commands[]

If any declared capability lacks a WhatsApp-executable command, the system MUST be classified as non-compliant under WFCS.

---

VIII. Command Declaration

A. Required Fields

Each command MUST declare:

• command_name (stable)

• intent:

  • entity
  • action
  • target_model (identifier type, optional)

• capability_id (back-reference)

• args_schema (JSON Schema-like structure or reference)

• normalization_rules (references or inline constraints)

• safety_class (see Section IX)

• confirmation_policy_id (binding to CCP confirmation semantics)

• authorization:

  • required_scopes[]
  • min_trust_level (ACSM)
  • step_up_policy_id (if applicable)

• idempotency_class (e.g., strict, windowed, none-for-readonly)

• presentation:

  • menu_labels[] (for numbered menus)
  • examples[] (NL examples)
  • disambiguation_strategy (list/select/ask)

• conversion_hooks (WWCS mappings; optional but recommended)

B. Read-only Commands

Read-only commands MUST declare:

• mutates_state = false
• confirmation_policy_id = none (or equivalent)
• idempotency_class MAY be none (but logging is still recommended)

---

IX. Safety Classification

The registry MUST classify commands into at least:

• S0 — Read-only: no mutation, no confirmation required
• S1 — Safe Mutation: reversible or low-impact; confirmation required (CCP)
• S2 — Destructive: cancel/delete/revoke/reset; strengthened confirmation required (CCP)
• S3 — Administrative High-Impact: scope/role/policy/secrets/billing; step-up required (ACSM)

The system MAY add finer granularity, but MUST map to these minimum classes.

---

X. Scope and Policy Binding

A. Required Scope Binding

Each state-mutating command MUST list at least one required_scope.
Admin commands MUST require admin-specific scopes (no generic “*”).

B. Policy References

confirmation_policy_id MUST resolve to a policy that defines:

• confirmation method
• token/phrase rules for destructive actions
• preview requirements

step_up_policy_id MUST resolve to a policy that defines:

• step-up triggers
• accepted methods
• freshness window

---

XI. Web-to-WhatsApp Conversion Hooks (WWCS Integration)

Commands SHOULD include conversion metadata enabling deterministic translation from web UI artifacts, such as:

• button IDs / action IDs → command_name
• form field mapping → args_schema fields
• table row actions → target resolution rules
• pagination/filters → read-only query commands

This enables “dashboard parity” without a web dependency (WFCS + WWCS).

---

XII. Versioning, Deprecation, and Compatibility

A. SemVer

The registry MUST use SemVer:

• MAJOR: breaking changes to command names, intent semantics, or required args
• MINOR: new capabilities/commands, optional fields
• PATCH: bugfixes, description changes, non-breaking clarifications

B. Deprecation Rules

Deprecated commands MUST declare:

• deprecated_since
• replacement_command (if any)
• removal_version (optional)

The system SHOULD support an alias period where old commands map to new ones, while preserving audit trace.

---

XIII. Compliance Evaluation Using CRCD

A system claiming WhatsApp-first compliance MUST pass:

1. Capability Coverage: all capabilities have WhatsApp-executable commands
2. Multimodal Coverage: capabilities respect WFCS input requirements
3. Admin Sovereignty: admin capabilities exist and are executable via WhatsApp
4. Safety Binding: every mutating command has confirmation policy
5. Security Binding: every mutating command has scopes; S3 has step-up policies
6. Traceability: command declarations support envelope tracing (CCP integration)

Failure in any check MUST classify the system as non-compliant.

---

XIV. Reference Implementation Requirements (Non-Normative)

Typical CRCD usage patterns:

• generate /help menus and capability discovery
• drive automated disambiguation (choose 1..N)
• power governance tooling (audit dashboards that are optional, not required)
• run static compliance checks in CI (“compliance-as-code”)

---

XV. Security Considerations

Registry exposure MUST be controlled:

• public exposure MAY leak operational surface area
• systems SHOULD provide redacted public views and privileged full views
• registry updates MUST be audited and protected by ACSM

---

XVI. Conclusion

CRCD makes WhatsApp-first auditable and automatable by declaring capabilities and commands as explicit, versioned, policy-bound artifacts. It enables deterministic conversational UX, compliance checks, secure execution gating, and long-term evolution without semantic drift.

---

References

[1] RFC-WF-0001, WhatsApp-First Compliance Core (WFCS).
[2] RFC-WF-0002, Web-to-WhatsApp Conversion Standard (WWCS).
[3] RFC-WF-0003, Conversational Command Protocol (CCP).
[4] RFC-WF-0004, Administrative Command Security Model (ACSM).

---

Concepts and Technologies

Capability registry, command declarations, intent mapping, JSON Schema-style args, SemVer governance, safety classes, scope binding, step-up policy references, web→whatsapp conversion hooks, compliance-as-code.