DEV Community

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

Posted on

FullAgenticStack WhatsApp-first: RFC-WF-0007

#agents #architecture #monitoring #systemdesign

RFC-WF-0007

Observability over Conversation (OoC)

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

Abstract

This document specifies Observability over Conversation (OoC) for WhatsApp-first systems. OoC defines normative requirements that make system state, operational status, errors, decisions, and evidence queryable and explainable via WhatsApp, without mandatory dashboards. OoC standardizes a conversational interface for observability signals (logs, metrics, traces, events) by binding them to commands, capabilities, and evidence artifacts. The objective is to ensure WhatsApp-first systems remain operable, debuggable, and auditable through conversation alone.

Index Terms— observability, conversational interfaces, logs, metrics, traces, evidence artifacts, incident response, WhatsApp-first.

I. Introduction

WhatsApp-first compliance requires that observability not be “dashboard-only.” If a user can execute operations via WhatsApp but cannot inspect failures, decisions, or progress without a web UI, the system becomes operationally dependent on out-of-band tooling—violating the WhatsApp-first spirit and often the letter (WFCS P7). OoC provides a normative framework for exposing the “four pillars” (logs, metrics, traces, events) as conversationally accessible observability.

OoC assumes CCP provides canonical commands and EAS provides standardized evidence. OoC defines how to query and summarize that evidence conversationally—safely, with redaction and access control.

II. Scope

OoC specifies:

  • Conversational observability commands and minimum query set
  • Required observability signals for WhatsApp-first operation
  • Evidence-driven responses bound to EAS artifacts
  • Correlation across command → trace → evidence → effects
  • Redaction and access control requirements for observability data
  • Incident/health summaries and progressive detail (“drill-down”) patterns

OoC does not define the internal telemetry stack (Prometheus, OpenTelemetry, etc.), only the conversational requirements and mappings.

III. Normative Language

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

IV. Definitions

OoC Query: A conversational request that retrieves or summarizes observability data.
Evidence-Backed Response: An observability answer that references standardized evidence artifacts (EAS).
Drill-down: Progressive disclosure from summary to details via numbered options.
Operational Actor: A user or agent with permissions to query operational telemetry.

V. Design Goals

OoC MUST ensure:

  • G1. Dashboard Independence: critical operational visibility is available via WhatsApp.
  • G2. Evidence-Backed: answers can be traced to EAS artifacts where applicable.
  • G3. Progressive Detail: summary-first, drill-down on demand to avoid chat overload.
  • G4. Safe Disclosure: redaction and least-privilege access for sensitive data.
  • G5. Correlation: links between command_id, correlation_id, evidence, and outcomes.

VI. Mandatory Observability Capabilities

A WhatsApp-first system MUST support, via WhatsApp, at least the following capability groups.

A. System Health and Service Status

The system MUST support a command equivalent to:

  • “system status” / “health” Returning at minimum:
  • overall status (ok | degraded | outage)
  • impacted services
  • current incident identifier (if any)
  • last update timestamp

B. Command and Operation Tracking

The system MUST allow a user to query:

  • status of a command (command_id)
  • last action performed
  • progress stage (from EAS lifecycle)
  • last error (if any)
  • how to retry / recover (if allowed)

C. Error and Failure Visibility

The system MUST provide:

  • last error for an operation
  • error reason code + human explanation
  • whether retryable
  • links (conversation options) to evidence and recovery actions

D. Decision and Policy Transparency

If the system uses authorization (ACSM), confirmation policies (CCP), or routing logic, OoC MUST be able to answer:

  • “why was this rejected?”
  • “which scopes were missing?” (redacted if necessary)
  • “which policy blocked this?”

E. Audit and Evidence Retrieval

Privileged users MUST be able to retrieve:

  • recent evidence artifacts for a command
  • evidence summary (what happened, who did it, what changed)

VII. Conversational Query Protocol

OoC queries MUST be implemented as CCP-compatible commands (read-only) and SHOULD be declared in CRCD.

A. Minimum Command Set (Normative)

Implementations MUST support at least:

  1. OOC.STATUS — system health summary
  2. OOC.LAST — last N operations for the actor/tenant
  3. OOC.CMD <command_id> — command lifecycle and outcome
  4. OOC.ERROR <command_id> — last error details (if any)
  5. OOC.EVIDENCE <command_id> — evidence summary + drill-down
  6. OOC.TRACE <correlation_id> — correlated chain across services (summary)

Natural language equivalents MUST be accepted (e.g., “what happened with order cancel 204?”), canonicalized into these commands.

B. Output Formatting Rules

OoC responses MUST:

  • present a concise summary first
  • provide numbered drill-down options (WWCS pattern)
  • include stable identifiers for follow-up (command_id, correlation_id)
  • avoid dumping raw logs unless explicitly requested and authorized

C. Drill-down Levels (Recommended)

OoC SHOULD provide:

  • Level 0: one-line status
  • Level 1: short summary + next actions
  • Level 2: evidence summary + key fields
  • Level 3: detailed artifact fields (redacted)
  • Level 4: raw payload excerpts (privileged only, rate-limited)

VIII. Evidence-Backed Response Requirements

When OoC answers about a command execution, it MUST be able to reference EAS fields, at minimum:

  • lifecycle.command_id, lifecycle.stage
  • security.authz.decision and reason if denied
  • payload.result.status, payload.result.summary
  • payload.result.error (when failed)
  • trace.correlation_id (if present)

OoC MAY provide a short “evidence digest”:

  • who
  • what
  • when
  • why (policy)
  • outcome
  • affected resources (if available)

IX. Correlation Semantics

A. Required Identifiers

OoC MUST support correlation using at least one of:

  • command_id
  • correlation_id (recommended)
  • conversation_id + message_id pair

B. Cross-Service Correlation

If a command triggers multiple services, OoC SHOULD present a summarized chain:

  • Service A: executed
  • Service B: failed (reason)
  • Service C: compensated

OoC MUST avoid leaking internal topology details to non-privileged actors.

X. Redaction and Access Control

OoC MUST enforce least privilege:

  • operational detail visibility MUST be scope-gated (ACSM)
  • secrets, tokens, and PII MUST be redacted by default
  • privileged “raw” views MUST require explicit step-up (recommended) for sensitive data

OoC MUST NOT expose:

  • plaintext credentials
  • integration secrets
  • full payment identifiers (unless policy allows)
  • internal keys or signing material

XI. Rate Limiting and Abuse Resistance

To prevent “observability scraping”:

  • OoC SHOULD rate-limit repeated queries
  • OoC SHOULD degrade detail level under suspicious patterns
  • OoC MUST record OoC queries as read-only evidence (optional: observation.emitted in EAS)

XII. Compliance Profiles

Implementations MAY declare:

  • OoC-Basic: status + command tracking + last error + evidence summary
  • OoC-Strong: basic + correlated chains + “why rejected” transparency
  • OoC-Operational: strong + conversational incident workflow + recovery suggestions

XIII. Relationship to Other RFCs

  • WFCS (RFC-WF-0001): mandates observability transparency over WhatsApp.
  • CCP (RFC-WF-0003): provides read-only command execution substrate for OoC queries.
  • CRCD (RFC-WF-0005): declares OoC commands/capabilities and binds them to scopes.
  • EAS (RFC-WF-0006): provides evidence artifact format OoC references in responses.

XIV. Security Considerations

OoC increases operational surface area. Implementations MUST:

  • enforce scope-based access
  • redact sensitive fields by default
  • prevent leaking multi-tenant data
  • log observability access for audit purposes
  • avoid enabling attackers to enumerate internal failures or topology

XV. Conclusion

OoC makes WhatsApp-first systems truly operable by ensuring that health, failures, decisions, and evidence are visible and explainable via conversation. Without OoC, “WhatsApp-first” becomes “WhatsApp-only execution,” which collapses during incidents. OoC completes the operational loop: execute, observe, explain, recover—inside WhatsApp.

References

[1] RFC-WF-0001, WhatsApp-First Compliance Core (WFCS).
[2] RFC-WF-0003, Conversational Command Protocol (CCP).
[3] RFC-WF-0005, Command Registry & Capability Declaration (CRCD).
[4] RFC-WF-0006, Evidence Artifact Schema (EAS).

Concepts and Technologies

Conversational observability, evidence-backed explanations, drill-down menus, correlation IDs, logs/metrics/traces/events mapping, redaction policies, scope-gated telemetry, incident visibility over chat.

Top comments (0)