DEV Community

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

Posted on

FullAgenticStack WhatsApp-first: RFC-WF-0034

#webdev #programming #rfc #opensource

RFC-WF-0034

Conversation State & Context Persistence (CSCP)

Status: Draft Standard
Version: 1.0.0
Date: 20 Nov 2025
Category: Standards Track
Author: FullAgenticStack Initiative
Dependencies: RFC-WF-0003 (CCP), RFC-WF-0005 (CRCD), RFC-WF-0006 (EAS), RFC-WF-0007 (OoC), RFC-WF-0018 (SMCL), RFC-WF-0019 (DRPC), RFC-WF-0021 (SECR), RFC-WF-0015 (PPGP)
License: Open Specification (Public, Royalty-Free)

Abstract

This document specifies Conversation State & Context Persistence (CSCP) for WhatsApp-first systems. CSCP defines normative requirements for modeling, persisting, and governing conversational context (active intents, session state, pending confirmations/approvals, carts, last targets) in a way that is deterministic, auditable, privacy-aware, and interoperable with command execution (CCP), observability (OoC), recovery (RCP/SMCL), and evidence (EAS). CSCP prevents “hidden state drift” by standardizing context lifecycles, expiry, and evidence linkage.

Index Terms— conversational context, session state, context persistence, pending confirmations, context expiry, privacy-aware state, WhatsApp-first.

I. Introduction

WhatsApp-first systems rely on conversation as the primary UI. That implies the system must maintain context across messages: what the user was doing, what step they are on, what entity they referenced, and what confirmations are pending. Without standard rules, implementations become fragile:

  • “yes” confirms the wrong action
  • old context persists too long and causes accidental operations
  • operators cannot debug “why the bot did that”
  • evidence lacks the context that made a command interpretable

CSCP standardizes context state so it remains safe, explainable, and auditable.

II. Scope

CSCP specifies:

  • Context model and required fields
  • Context lifecycle states and expiry rules
  • Binding context to CCP envelopes and EAS evidence
  • Multi-tenant and privacy constraints for context data (DRPC)
  • OoC inspection of context (redacted)
  • Policy-driven context rules (PPGP)
  • Compatibility and extension rules (SECR)

CSCP does not define storage engines; it defines behavioral semantics.

III. Normative Language

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

IV. Definitions

Conversation Context: Persisted state describing the current conversational situation.
Context Slot: A named piece of context (e.g., active_order_id, pending_confirmation).
Context Frame: A snapshot of context at a point in time, linked to messages and commands.
Expiry: Automatic invalidation of context after a policy-defined time or after terminal transitions.

V. Design Goals

CSCP MUST ensure:

  • G1. Safety: prevent wrong confirmations and stale context actions.
  • G2. Determinism: same message sequence leads to same context transitions.
  • G3. Auditability: context frames can be linked to command evidence.
  • G4. Privacy: context stores minimal necessary data with retention limits.
  • G5. Interop: tools can inspect context in a standardized redacted form.

VI. Context Model (Normative)

A. Required Fields

A context record MUST include:

  • context_id (unique)
  • tenant_id
  • conversation_id
  • actor_id (principal)
  • status (active|pending|blocked|expired|closed)
  • created_at, updated_at
  • expires_at (policy-driven)
  • slots (key-value structure)

  • trace:

    • last_message_id
    • optional last_command_id
    • optional correlation_id

B. Context Slots (Minimum Set)

Implementations MUST support at least:

  • active_intent (current intent label or command_name candidate)
  • active_target (e.g., last selected entity id)
  • pending_confirmation (if any)
  • pending_approval (if any)
  • last_result (summary/status of last command)
  • work_item_id (if in operator workflow context)

Systems MAY add slots (cart, address, payment_state) via extensions.

VII. Context Lifecycle (Normative)

A. States

  • active: usable context for interpretation
  • pending: awaiting user input (disambiguation/confirmation/approval)
  • blocked: waiting on external completion or operator action
  • expired: no longer valid; MUST NOT be used for execution
  • closed: terminal; optionally archived for audit within retention policy

B. Transition Rules

  • active → pending when the system requests disambiguation/confirmation/approval
  • pending → active when required input is provided but execution not yet terminal
  • pending → expired when expires_at is reached
  • active/pending → closed when conversation is finalized or policy dictates
  • blocked → active when the blocking condition resolves
  • blocked → expired on timeout

C. Expiry Invariant

Expired context MUST NOT be used to interpret “yes/no” responses or to select targets. Instead, the system MUST request re-selection or re-confirmation.

VIII. Binding Context to Commands (CCP)

A. Snapshot-on-Execute

When a CCP command envelope is created (canonicalized), the system MUST link:

  • context_id
  • a context snapshot reference (or hash)
  • the message ids used for interpretation

This ensures auditors can reconstruct what context influenced command formation.

B. Pending Confirmation Safety

If a confirmation is pending, the context MUST store:

  • pending_confirmation.command_id
  • pending_confirmation.idempotency_key
  • pending_confirmation.target_fingerprint (recommended)

A generic “yes” MUST only confirm the currently pending confirmation within its validity window; otherwise it MUST be rejected as ambiguous.

IX. Evidence Requirements (EAS Integration)

Evidence artifacts SHOULD include a context_ref (extension-safe under SECR), containing:

  • context_id
  • optional context_frame_id or context_hash
  • expires_at (optional)

At minimum, the evidence MUST be traceable to the same conversation_id and message_ids that the context uses.

X. OoC Context Inspection (Redacted)

Privileged OoC MUST support a query like:

  • “show active context”

and return:

  • context status and expiry
  • active intent and target (redacted as needed)
  • pending confirmation/approval existence (not secrets/tokens)
  • last command status

OoC MUST apply redaction and least privilege (DRPC/PPGP).

XI. Privacy and Retention (DRPC Alignment)

A. Minimization

Context stores MUST NOT duplicate raw message content unless necessary. Prefer storing:

  • references (message_id)
  • stable identifiers (order_id)
  • redacted summaries

B. Retention

Context records MUST have retention policies, potentially shorter than evidence. Closed/expired contexts SHOULD be purged or archived according to policy.

XII. Policy Binding (PPGP)

Policies MUST be able to configure:

  • default context TTL
  • confirmation TTL
  • approval TTL
  • whether certain slots are stored or derived on demand
  • context detail levels available in OoC

XIII. Compatibility and Extensions (SECR)

Custom slots MUST use extensions or x_* naming to avoid collisions. Consumers MUST ignore unknown slots.

XIV. Conformance Requirements

An implementation is CSCP-compliant if it:

  1. persists context with required fields and lifecycle states
  2. enforces expiry invariants (no stale confirmation execution)
  3. binds context to command envelopes and evidence
  4. exposes redacted context inspection via OoC (privileged)
  5. enforces minimization and retention constraints

XV. Security Considerations

Context is a common attack surface: attackers try to exploit stale context (“yes” to old destructive action), or to poison context with ambiguous references. CSCP requires expiry, target binding, and OoC visibility (for debugging) to reduce these risks.

XVI. Conclusion

CSCP makes conversational systems stable and safe by standardizing how context is stored, expires, and binds to command execution and evidence. This closes a critical gap in WhatsApp-first: preventing hidden state from silently controlling operations without auditability.

References

[1] RFC-WF-0003, Conversational Command Protocol (CCP).
[2] RFC-WF-0005, Command Registry & Capability Declaration (CRCD).
[3] RFC-WF-0006, Evidence Artifact Schema (EAS).
[4] RFC-WF-0007, Observability over Conversation (OoC).
[5] RFC-WF-0018, State Model & Command Lifecycle (SMCL).
[6] RFC-WF-0019, Data Retention, Redaction & Privacy over Conversation (DRPC).
[7] RFC-WF-0021, Schema Extensions & Compatibility Rules (SECR).
[8] RFC-WF-0015, Policy Packs & Governance Profiles (PPGP).

Concepts and Technologies

Context frames, pending confirmation binding, expiry invariants, context minimization, redacted context inspection, conversational session state, evidence-linked interpretation, policy-driven TTLs, extension-safe slots.

Top comments (0)