DEV Community

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

Posted on

FullAgenticStack WhatsApp-first: RFC-WF-0031

#architecture #cicd #devops #systemdesign

RFC-WF-0031

Deployment & Environment Separation Requirements (DESR)

Status: Draft Standard
Version: 1.0.0
Date: 20 Nov 2025
Category: Standards Track
Author: FullAgenticStack Initiative
Dependencies: RFC-WF-0004 (ACSM), RFC-WF-0011 (CATS), RFC-WF-0015 (PPGP), RFC-WF-0018 (SMCL), RFC-WF-0019 (DRPC), RFC-WF-0020 (RAOS), RFC-WF-0025 (CABM)
License: Open Specification (Public, Royalty-Free)

Abstract

This document specifies Deployment & Environment Separation Requirements (DESR) for WhatsApp-first systems. DESR defines normative requirements for separating dev/test/staging/prod environments, isolating tenants, controlling policy packs per environment, enforcing sandbox safety, and preventing cross-environment evidence/telemetry leakage. DESR ensures that WhatsApp-first systems remain auditable and safe across deployments, and that compliance attestations (CABM) are environment-specific and verifiable.

Index Terms— environment separation, staging vs production, sandbox tenants, policy isolation, audit safety, operational governance.

I. Introduction

WhatsApp-first systems make it easy to operate production flows conversationally—which also makes it easy to accidentally operate production when you meant to test. DESR defines the minimum separation and safeguards needed to:

  • avoid cross-environment contamination (evidence, telemetry, data)
  • ensure sandbox testing for CATS/TVRS does not affect production
  • prevent “policy drift” between staging and prod
  • keep compliance claims meaningful (attestation must specify environment)

II. Scope

DESR specifies:

  • environment classification and required invariants
  • tenant isolation requirements across environments
  • policy pack/profile binding by environment
  • sandbox execution constraints for tests and PoCs
  • evidence and telemetry isolation requirements
  • deployment safety checks for high-impact operations
  • attestation environment scoping requirements

DESR does not prescribe CI/CD pipelines; it defines constraints.

III. Normative Language

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

IV. Definitions

Environment: A deployment context such as dev, test, staging, or prod.
Sandbox Tenant: A tenant reserved for non-production conformance tests and demos.
Policy Drift: Untracked divergence between policy packs across environments.
Cross-Environment Leakage: Evidence, telemetry, or data accessible across environments.

V. Design Goals

DESR MUST ensure:

  • G1. Safety: testing cannot mutate production state.
  • G2. Isolation: evidence and telemetry are environment-scoped.
  • G3. Governance: policies are explicit per environment and auditable.
  • G4. Verifiable Claims: attestations identify environment and validity window.
  • G5. Operational Clarity: conversation responses clearly indicate environment in privileged views.

VI. Environment Model (Normative)

Implementations MUST classify deployments into:

  • dev
  • test
  • staging
  • prod

Each evidence artifact MUST include system.environment (EAS).

VII. Tenant Isolation Across Environments

A. Hard Isolation Requirement

A tenant in one environment MUST NOT share:

  • databases
  • evidence stores
  • caches
  • message queues
  • connector credentials

with a tenant in another environment, unless explicitly designed and audited with strict separation mechanisms.

B. Identifier Scoping

Tenant identifiers SHOULD be namespaced by environment (e.g., prod:tenant_1) to prevent accidental cross-use.

VIII. Policy Packs by Environment (PPGP Alignment)

A. Explicit Binding

Each environment MUST bind a specific policy pack version + profile (PPGP). The binding MUST be auditable.

B. Fail-Closed in Production

In prod, missing policies for high-impact actions MUST fail closed (no execution).

C. Drift Detection

Systems SHOULD provide an OoC query for privileged users to report:

  • active policy pack id/version
  • active profile
  • last policy change evidence reference

IX. Sandbox Mode Requirements (CATS/TVRS Safety)

A. Sandbox Tenant

Systems MUST provide a sandbox tenant (or equivalent mode) where:

  • destructive operations are either blocked or redirected to mock resources
  • financial connectors use test-mode providers
  • data retention is shorter and clearly labeled (optional)

B. Guardrails

In sandbox mode:

  • confirmation/approval flows MUST still be enforced (don’t “cheat” the spec)
  • evidence MUST still be emitted (EAS)
  • OoC and RCP must remain functional

C. Preventing Accidental Production Calls

Sandbox mode MUST NOT hold production secrets or production connector credentials.

X. Evidence and Telemetry Isolation

A. Evidence Store Separation

Evidence stores MUST be environment-scoped. Evidence queries MUST not return artifacts from other environments.

B. Telemetry Separation

Logs/metrics/traces MUST be environment-scoped. If a shared observability backend is used, environment partitioning MUST be enforced.

C. Retention Differences

DRPC retention policies MAY differ per environment, but MUST be explicit and auditable.

XI. Deployment Safety Checks

A. High-Impact Actions in Prod

For S3/R3 actions in prod, the system SHOULD:

  • require stronger step-up or approvals (HAPF profile)
  • require explicit environment acknowledgement in the preview (“PROD”)
  • log the environment label in evidence

B. Lockdown and Maintenance

RAOS lockdown mode SHOULD be available in prod via WhatsApp admin controls, and MUST be evidenced.

XII. Attestation Requirements (CABM Alignment)

Any compliance attestation MUST include:

  • environment
  • tenant_scope
  • discovery URL (WKD)
  • validity window

Attestations MUST NOT be reused across environments.

XIII. Conformance Requirements

An implementation is DESR-compliant if it:

  1. tags all evidence with environment
  2. prevents cross-environment evidence access
  3. binds and audits policy packs per environment
  4. supports sandbox tenant/test mode for conformance checks
  5. prevents sandbox credentials from invoking production connectors
  6. produces environment-scoped attestations

XIV. Security Considerations

Cross-environment leakage is a frequent real-world failure mode. DESR reduces blast radius by enforcing hard separation. The main risk is operational complexity; tooling should make environment visibility explicit in OoC and previews to prevent human mistakes.

XV. Conclusion

DESR ensures WhatsApp-first systems remain safe and auditable across deployment environments. By enforcing environment tagging, tenant isolation, policy pack separation, sandbox guardrails, and environment-scoped attestations, DESR prevents “testing by accident in prod” and keeps compliance claims meaningful.

References

[1] RFC-WF-0004, Administrative Command Security Model (ACSM).
[2] RFC-WF-0011, Compliance Audit Toolkit Spec (CATS).
[3] RFC-WF-0015, Policy Packs & Governance Profiles (PPGP).
[4] RFC-WF-0018, State Model & Command Lifecycle (SMCL).
[5] RFC-WF-0019, Data Retention, Redaction & Privacy over Conversation (DRPC).
[6] RFC-WF-0020, Rate Limits, Abuse Controls & Operational Safety (RAOS).
[7] RFC-WF-0025, Certification Attestation & Badge Metadata (CABM).

Concepts and Technologies

Environment scoping, sandbox tenants, policy drift detection, evidence/telemetry isolation, production guardrails, connector credential separation, environment-aware attestations, staged deployments.

Top comments (0)