DEV Community

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

Posted on

FullAgenticStack WhatsApp-first: RFC-WF-0011

#agents #automation #security #testing

RFC-WF-0011

Compliance Audit Toolkit Spec (CATS)

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-0005 (CRCD), RFC-WF-0006 (EAS), RFC-WF-0007 (OoC), RFC-WF-0008 (RCP), RFC-WF-0009 (TMSI), RFC-WF-0010 (IDS)
License: Open Specification (Public, Royalty-Free)

Abstract

This document specifies the Compliance Audit Toolkit Spec (CATS) for WhatsApp-first systems. CATS defines a standard audit manifest, a normative set of automatable checks, and required evidence outputs to assess and certify WhatsApp-first compliance. CATS enables “compliance-as-code” by transforming RFC requirements into executable validations across capability coverage, command safety, security invariants, evidence completeness, observability availability, and recovery operability—without requiring proprietary tooling.

Index Terms— compliance-as-code, certification, audit toolkit, manifests, automated checks, evidence artifacts, WhatsApp-first.

I. Introduction

A specification becomes real when it is testable. WhatsApp-first compliance is binary in WFCS, but production systems need a repeatable mechanism to prove they satisfy parity, safety, security, evidence, observability, and recovery requirements. CATS defines the required artifacts and checks for an audit toolkit that can be run locally, in CI, or during certification.

CATS is intentionally vendor-neutral: it defines data formats and check semantics, not an implementation language.

II. Scope

CATS specifies:

  • The WFS Compliance Manifest format (YAML/JSON)
  • A minimum check suite with normative pass/fail rules
  • Evidence requirements and report formats
  • Audit execution modes (static vs runtime sampling)
  • Mapping to certification levels (optional but recommended)

CATS does not define pricing, branding, or program governance; it defines the technical substrate.

III. Normative Language

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

IV. Definitions

Audit Manifest: A declarative file describing the system, registry endpoints, evidence stores, and capability claims to be validated.
Static Check: Validation of declared artifacts (CRCD registry, policies, schemas).
Runtime Check: Validation of behavior by executing test commands and inspecting evidence (EAS) and OoC responses.
Control: A single atomic compliance requirement with an identifier and pass/fail criteria.

V. Design Goals

CATS MUST ensure:

  • G1. Deterministic Audits: Same inputs yield same audit decisions.
  • G2. Automatable: Controls are machine-executable (static and/or runtime).
  • G3. Evidence-Backed: Fail/pass decisions can be justified with EAS references.
  • G4. Minimal Intrusion: Runtime checks can run in sandbox/tenant without disrupting production.
  • G5. Extensibility: Controls can be expanded without breaking manifest compatibility.

VI. WFS Compliance Manifest (WCM)

A. Format

The system under audit MUST provide a WCM file in YAML or JSON.

B. Required Top-Level Fields

The manifest MUST include:

  • manifest_version (SemVer)
  • system (id, name, environment, owner)
  • targets (endpoints/paths to registry, evidence, and OoC)
  • claims (declared compliance claims, optional but recommended)
  • scoping (tenant/test account constraints)
  • policies (redaction and safe testing constraints)

C. Example (YAML) 

manifest_version: "1.0.0"
system:
  system_id: "acme-pharma-wos"
  name: "ACME WhatsApp Operating System"
  environment: "staging"
  owner: "ACME"
targets:
  crcd_registry:
    type: "http"
    url: "https://example.com/.well-known/wfs/crcd.json"
  evidence_store:
    type: "http"
    query_url: "https://example.com/.well-known/wfs/evidence/query"
  ooc:
    type: "command"
    entrypoint: "whatsapp"
    test_actor: "auditor-bot"
scoping:
  tenant_id: "tenant-staging-001"
  test_mode: true
policies:
  redaction: "default"
  safe_testing: true
Enter fullscreen mode Exit fullscreen mode

Implementations MAY replace URLs with local file paths in CI.

VII. Control Catalog (Minimum Set)

CATS defines a minimum set of controls. Each control MUST have:

  • control_id (stable)
  • category
  • method (static | runtime | hybrid)
  • requirement (normative statement)
  • evidence (what is collected)
  • pass_criteria / fail_criteria

A. Foundation Controls (WFCS)

  • WFS-C-001 Capability Parity (static/hybrid)

    • Requirement: All declared capabilities MUST be WhatsApp-executable.
    • Pass: CRCD shows 100% capability coverage with commands.

  • WFS-C-002 Multimodal Input (runtime/hybrid)

    • Requirement: Commands MUST accept text and audio (STT) where mandated.

  • WFS-C-003 No Dashboard-Only Mutations (hybrid)

    • Requirement: No mutation of state exists that is only possible via web/dashboard.

B. Command Safety Controls (CCP + IDS)

  • WFS-C-010 Canonical Envelope Execution (static/runtime)
  • WFS-C-011 Confirmation for Mutations (runtime)
  • WFS-C-012 Strengthened Confirmation for Destructive (runtime)

  • WFS-C-013 Idempotency Under Duplicates (runtime)

    • Deliver same mutation twice; verify exactly-once effects via EAS.

C. Security Controls (ACSM + TMSI)

  • WFS-C-020 Scope Gating (static/runtime)
  • WFS-C-021 Step-up for High-Impact (runtime)
  • WFS-C-022 Ambiguity Rejection (runtime)
  • WFS-C-023 Agent Non-Bypass (static/runtime if agents exist)

D. Evidence Controls (EAS)

  • WFS-C-030 Evidence Completeness (runtime)
  • WFS-C-031 Evidence Immutability (Append-only) (hybrid)
  • WFS-C-032 Evidence Integrity Fields Present (static)

E. Observability Controls (OoC)

  • WFS-C-040 Conversational Status (runtime)
  • WFS-C-041 Error Transparency (runtime)
  • WFS-C-042 Evidence Drill-down (runtime)
  • WFS-C-043 Redaction & Least Privilege (runtime)

F. Recovery Controls (RCP)

  • WFS-C-050 Recovery Options Available (runtime)
  • WFS-C-051 Retry Is Governed and Evidenced (runtime)
  • WFS-C-052 Compensation Is Governed and Evidenced (runtime, where applicable)

VIII. Audit Execution Modes

A. Static Audit

Static audits MUST validate:

  • CRCD registry structure and required fields
  • presence of OoC and RCP command declarations
  • mapping of commands to scopes and policies
  • IDS idempotency class declarations and TTLs
  • EAS schema conformance for sample artifacts (if provided)

B. Runtime Audit

Runtime audits MUST:

  1. Execute a small set of safe test commands (read-only + controlled mutations)
  2. Trigger duplicates for idempotency validation
  3. Query OoC for status and error transparency
  4. Query evidence store for EAS artifacts
  5. Validate recovery behavior in a sandbox scope

Runtime audits MUST respect safe_testing policy and MUST avoid destructive operations outside a test tenant.

C. Hybrid Audit

Hybrid audits combine static registry checks with runtime sampling.

IX. Required Outputs

A CATS-compliant toolkit MUST output:

  • Audit Report (JSON) containing:

    • tool version
    • manifest hash
    • control results (pass/fail/skip)
    • evidence references (artifact_ids, command_ids)
    • reasons for failures

  • Human Summary (Markdown) containing:

    • executive summary
    • critical failures
    • recommended remediations (control-by-control)

Optional outputs MAY include PDF or signed attestations.

X. Certification Mapping (Optional)

Implementations MAY map controls to certification levels, for example:

  • Bronze: Foundation + basic command safety
  • Silver: Bronze + OoC + evidence completeness
  • Gold: Silver + IDS strong + governed recovery + stronger security checks
  • Platinum: Gold + advanced agent constraints + negotiated observability + auto-optimization

This mapping is informational and not required for conformance.

XI. Security Considerations

Audit tooling can be abused. Implementations MUST:

  • scope audits to a tenant/test environment
  • ensure OoC and evidence queries respect least privilege
  • redact secrets and PII in reports by default
  • require step-up for privileged runtime checks if necessary

XII. Relationship to Other RFCs

CATS operationalizes the requirements defined by:

  • WFCS (0001): parity and WhatsApp-first constraints
  • WWCS (0002): conversion patterns availability (indirectly audited via registry)
  • CRCD (0005): source of declared capabilities/commands/policies
  • EAS (0006): evidence format validated and referenced
  • OoC (0007): conversational observability validated
  • RCP (0008): recovery operability validated
  • TMSI (0009): security invariants validated
  • IDS (0010): idempotency semantics validated

XIII. Conclusion

CATS transforms WhatsApp-first from a document into an auditable, automatable standard. By defining a manifest format, a minimal control catalog, runtime sampling behavior, and evidence-backed reporting, it enables certification and continuous compliance enforcement (“compliance-as-code”) across diverse implementations.

References

[1] RFC-WF-0001, WhatsApp-First Compliance Core (WFCS).
[2] RFC-WF-0002, Web-to-WhatsApp Conversion Standard (WWCS).
[3] RFC-WF-0005, Command Registry & Capability Declaration (CRCD).
[4] RFC-WF-0006, Evidence Artifact Schema (EAS).
[5] RFC-WF-0007, Observability over Conversation (OoC).
[6] RFC-WF-0008, Recovery & Compensation Protocol (RCP).
[7] RFC-WF-0009, Threat Model & Security Invariants (TMSI).
[8] RFC-WF-0010, Idempotency & Delivery Semantics (IDS).

Concepts and Technologies

Compliance-as-code, manifests, static/hybrid/runtime audits, control catalogs, evidence-backed certification, sandbox tenants, redaction policies, registry-driven validation, idempotency tests, conversational observability tests, governed recovery tests.

Top comments (0)