FullAgenticStack WhatsApp-first: RFC-WF-0018

Source: Dev.to

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
• Valid transitions
• Terminal conditions
• 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.

Relationship to Other RFCs

Implementations often diverge on lifecycle stages and transition ordering, breaking interoperability and audits. SMCL provides a single normative lifecycle FSM that:

1. Standardizes state naming
2. Constrains valid transitions
3. Defines terminal states
4. Specifies required evidence for each transition
5. Formalizes idempotent re‑entry behavior under duplicates/retries

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

The usual RFC normative keywords (MUST, MUST NOT, SHOULD, SHOULD NOT, MAY) apply.

Terminology

Primary‑Command Lifecycle States

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.
• 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.

Allowed Transitions

The following transitions MUST be enforced:

received               → canonicalized
canonicalized          → confirmation_required   (if mutating and not auto‑confirmed by policy)
confirmation_required → confirmed
canonicalized          → authz_pending          (read‑only or pre‑confirm validation path allowed)
confirmed              → authz_pending
authz_pending          → authorized
authz_pending          → rejected
authorized             → started
started                → executed
started                → failed
started                → canceled
failed                 → compensated            (only if compensation executed successfully)
executed               → compensated            (allowed only if business‑defined compensation exists and is governed)

Invalid Transitions

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

1. Reject the transition.
2. Emit evidence indicating invalid_transition_attempt.
3. Preserve the prior terminal state.

Additional constraints:

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

Idempotency & Duplicate Handling

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

  • Terminal state (executed | rejected | canceled | compensated): the system MUST replay the outcome and MUST NOT re‑enter execution.
  • Started: duplicates MUST return an in_progress view and MUST NOT create parallel executions.

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

Recovery‑Command Rules

Recovery commands follow the same FSM with the following additional rules:

1. Reference the target_command_id.
2. Emit evidence linking to the target.
3. Respect authorization/confirmation/step‑up according to risk class (RCP/ACSM/PPGP).

Compensation Model

1. target_command is in failed or executed (depending on business semantics).
2. A recovery command executes the compensation plan.
3. target_command enters compensated only when the plan succeeds and evidence confirms convergence.

• Compensation MUST be append‑only and auditable.

Evidence Emission

For each lifecycle transition, the system MUST emit an evidence artifact containing at least:

• lifecycle.command_id
• lifecycle.transition (e.g., received→canonicalized)
• lifecycle.timestamp
• lifecycle.evidence_type (e.g., state_change, invalid_transition_attempt)
• Any additional context required by the dependent RFCs (CCP, EAS, RCP, IDS).

The exact schema is defined in RFC‑WF‑0006 (EAS).

Conformance

• Minimal conformance tests are mapped in RFC‑WF‑0017 (TVRS/CATS).
• Implementations MUST pass all TVRS test vectors that exercise each state, transition, terminal condition, and evidence emission requirement.

Security & Privacy Considerations

• All evidence artifacts MUST be signed and tamper‑evident.
• Sensitive fields (e.g., user identifiers) MUST be redacted or encrypted per the privacy policy defined in RFC‑WF‑0003 (CCP).

IANA Considerations

• No IANA actions are required.

References

• [RFC‑WF‑0003] Command Envelopes & Confirmation (CCP)
• [RFC‑WF‑0006] Evidence Artifacts (EAS)
• [RFC‑WF‑0008] Recovery Actions (RCP)
• [RFC‑WF‑0010] Replay‑Safe Execution (IDS)
• [RFC‑WF‑0017] Test Vector Reference Suite (TVRS/CATS)

Lifecycle State Mapping

Trace bindings: (conversation_id, message_ids)
Security decisions: include authz, step‑up, and confirmation when relevant.

X. Observability Requirements (OoC Compatibility)

OoC MUST be able to report, at minimum:

• Current lifecycle state.
• Last transition timestamp.
• Terminal outcome (if the state is terminal).
• Reason for rejection / failure (policy / reason code).
• Next allowed recovery options (if any).

An SMCL‑compliant implementation MUST pass tests that validate:

1. Invalid transition rejection – attempts to move to an illegal state are denied.
2. Ordering invariants – e.g., no start without prior confirm + authorize.
3. Duplicate handling – re‑sending a command does not re‑enter execution.
4. Evidence emission – required artifacts are emitted at each mandated transition.

These tests SHOULD be represented as TVRS (Test Vectors & Reference Scenarios) scenarios.

Related Specifications

Security & Consistency Notes

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

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. Evidence Artifact Schema (EAS).
3. Recovery & Compensation Protocol (RCP).
4. Idempotency & Delivery Semantics (IDS).
5. Test Vectors & Reference Scenarios (TVRS).

Keywords: finite‑state machines, lifecycle invariants, terminal‑state protection, evidence emission mapping, idempotent re‑entry rules, recovery/compensation state modeling, conformance testing.