DEV Community

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

Posted on

FullAgenticStack WhatsApp-first: RFC-WF-0018

#agents #architecture #computerscience #systemdesign

RFC-WF-0018

State Model & Command Lifecycle (SMCL)

Status: Draft Standard
Version: 1.0.0
Date: 20 Nov 2025
Category: Standards Track
Author: FullAgenticStack Initiative
Dependencies: RFC-WF-0003 (CCP), RFC-WF-0006 (EAS), RFC-WF-0008 (RCP), RFC-WF-0010 (IDS), RFC-WF-0017 (TVRS)
License: Open Specification (Public, Royalty-Free)

Abstract

This document specifies the State Model & Command Lifecycle (SMCL) for WhatsApp-first systems. SMCL defines a normative finite-state machine (FSM) for command execution and recovery, including allowed states, transitions, terminal conditions, and evidence emission requirements. SMCL ensures that all components (command execution, security gating, observability, recovery/compensation, and auditing) use a consistent lifecycle model—preventing stage drift and enabling deterministic tooling and certification.

Index Terms— finite-state machine, lifecycle states, command execution, recovery states, evidence emission, idempotency, distributed systems.

I. Introduction

CCP defines command envelopes and confirmation semantics; EAS defines evidence artifacts; RCP defines recovery actions; IDS defines replay-safe execution. However, implementations often diverge on lifecycle stages and transition ordering, breaking interoperability and audits. SMCL provides a single normative lifecycle FSM that:

  • standardizes state naming
  • constrains valid transitions
  • defines terminal states
  • specifies required evidence for each transition
  • formalizes idempotent re-entry behavior under duplicates/retries

II. Scope

SMCL specifies:

  • A canonical command lifecycle FSM for primary commands
  • A canonical lifecycle for recovery commands and compensation
  • Transition constraints and invalid transition handling
  • Evidence emission requirements per lifecycle stage
  • Idempotent re-entry and outcome replay semantics alignment with IDS
  • Minimal conformance tests mapping (TVRS/CATS)

SMCL does not define internal workflow engines; it defines observable behavior.

III. Normative Language

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

IV. Definitions

Primary Command: The original command requested by the user.
Recovery Command: A command that retries/cancels/reprocesses/compensates a primary command.
Lifecycle State: The current stage in the FSM.
Transition: Allowed movement from one state to another.
Terminal State: A state after which no further execution transitions may occur (except governed recovery).

V. Canonical Lifecycle FSM (Primary Commands)

A. States (Normative Set)

Every primary command MUST be modeled with the following states:

  • S0: received — raw input received (pre-envelope)
  • S1: canonicalized — envelope created and persisted
  • S2: confirmation_required — confirmation requested (if mutating)
  • S3: confirmed — confirmation satisfied
  • S4: authz_pending — authorization evaluation pending
  • S5: authorized — authorization granted
  • S6: rejected — rejected (validation, authz deny, policy deny, ambiguity) (terminal)
  • S7: started — execution started (effects may begin)
  • S8: executed — execution completed successfully (terminal)
  • S9: failed — execution failed (terminal for primary execution; recovery may follow)
  • S10: canceled — execution canceled / halted (terminal)
  • S11: compensated — compensation completed (terminal)

Notes:

  • Read-only commands MAY skip confirmation states (S2/S3).
  • Some implementations may merge authz_pending/authorized; if so, they MUST still expose semantically equivalent evidence and ordering.

B. State Meanings

  • received is pre-envelope and MUST NOT mutate state.
  • canonicalized is the earliest point where command_id exists.
  • confirmed indicates the human confirmation gate is satisfied.
  • authorized indicates scope/step-up gates are satisfied.
  • started indicates execution has begun and side effects may occur.
  • executed indicates effects are completed and consistent.
  • failed indicates execution ended with error; recovery may be possible.
  • compensated indicates compensation achieved a defined terminal correction.

VI. Transition Rules (Normative)

A. Allowed Transitions (Primary Commands)

Implementations MUST enforce the following allowed transitions:

  1. received → canonicalized
  2. canonicalized → confirmation_required (if mutating and not auto-confirmed by policy)
  3. confirmation_required → confirmed
  4. canonicalized → authz_pending (read-only or pre-confirm validation path allowed)
  5. confirmed → authz_pending
  6. authz_pending → authorized OR authz_pending → rejected
  7. authorized → started
  8. started → executed OR started → failed OR started → canceled
  9. failed → compensated (only if compensation executed successfully)
  10. executed → compensated (allowed only if business-defined compensation exists and is governed)

B. Invalid Transitions

If an invalid transition is attempted (e.g., executed → started), the system MUST:

  • reject the transition,
  • emit evidence indicating invalid_transition_attempt, and
  • preserve the prior terminal state.

C. Confirmation Ordering Invariant

For any mutating command, started MUST NOT occur unless confirmed has occurred (except explicit, policy-declared “safe auto-confirm” which MUST be auditable and rare).

D. Authorization Ordering Invariant

For any mutating command, started MUST NOT occur unless authorized has occurred.

VII. Idempotent Re-entry and Duplicate Handling (IDS Alignment)

A. Duplicate Deliveries

If the same logical command is delivered multiple times (same idempotency_key):

  • If the command is in a terminal state (executed|rejected|canceled|compensated), the system MUST replay the outcome and MUST NOT re-enter execution.
  • If the command is started, duplicates MUST return an in_progress view and MUST NOT create parallel executions.

B. Re-entry Restrictions

A primary command MUST NOT re-enter started once it has reached executed, rejected, canceled, or compensated.

VIII. Recovery Lifecycle (RCP Integration)

A. Recovery Commands Are First-Class Commands

Recovery commands MUST follow the same FSM, with these additional rules:

  • Recovery commands MUST reference target_command_id.
  • Recovery commands MUST emit evidence linking to the target.
  • Recovery commands MUST respect authorization/confirmation/step-up according to risk class (RCP/ACSM/PPGP).

B. Compensation Flow

Compensation is modeled as:

  • target_command in failed or executed (depending on business semantics)
  • recovery command executes compensation plan
  • target enters compensated only when plan succeeds and evidence confirms convergence

Compensation MUST be append-only and auditable.

IX. Evidence Emission Requirements (EAS Binding)

For each lifecycle transition, the system MUST emit an evidence artifact with:

  • lifecycle.command_id
  • lifecycle.stage corresponding to the new state
  • trace bindings (conversation_id, message_ids)
  • security decisions when relevant (authz/step-up/confirmation)

Minimum Evidence Map (Normative)

  • canonicalized → command.accepted
  • confirmation_required → command.confirmation.requested
  • confirmed → command.confirmation.satisfied
  • authorized/rejected → authz.decided (allow/deny)
  • started → execution.started
  • executed/failed/rejected → execution.executed | execution.failed | execution.rejected
  • compensated → compensation.compensated

X. Observability Requirements (OoC Compatibility)

OoC MUST be able to report, at minimum:

  • current lifecycle state
  • last transition timestamp
  • terminal outcome (if terminal)
  • why rejected/failed (policy/reason code)
  • next allowed recovery options (if any)

XI. Conformance Tests (TVRS Mapping)

An SMCL-compliant implementation MUST pass tests validating:

  • invalid transition rejection
  • ordering invariants (no start without confirm+authorize)
  • duplicate handling does not re-enter execution
  • evidence emitted at required transitions

These tests SHOULD be represented as TVRS scenarios.

XII. Relationship to Other RFCs

  • CCP (0003): defines envelope creation and confirmation; SMCL fixes ordering/stages.
  • EAS (0006): defines artifact structure; SMCL defines when artifacts must be emitted.
  • RCP (0008): defines recovery operations; SMCL defines their lifecycle constraints.
  • IDS (0010): defines replay-safe execution; SMCL defines re-entry rules.
  • TVRS (0017): supplies conformance scenarios for lifecycle behavior.

XIII. Security Considerations

Lifecycle inconsistencies can create bypasses (“start before authz”). Implementations MUST enforce invariants and log invalid attempts as evidence artifacts. Terminal state protection is critical to prevent replay abuse and “double effect” attacks.

XIV. Conclusion

SMCL provides the deterministic backbone for WhatsApp-first execution semantics: a canonical FSM that standardizes lifecycle states, transitions, evidence emission points, and idempotent re-entry behavior. This prevents lifecycle drift across services and enables reliable observability, recovery, and certification tooling.

References

[1] RFC-WF-0003, Conversational Command Protocol (CCP).
[2] RFC-WF-0006, Evidence Artifact Schema (EAS).
[3] RFC-WF-0008, Recovery & Compensation Protocol (RCP).
[4] RFC-WF-0010, Idempotency & Delivery Semantics (IDS).
[5] RFC-WF-0017, Test Vectors & Reference Scenarios (TVRS).

Concepts and Technologies

Finite-state machines, lifecycle invariants, terminal state protection, evidence emission mapping, idempotent re-entry rules, recovery/compensation state modeling, conformance testing.

Top comments (0)