suissAI

Posted on Feb 26

FullAgenticStack WhatsApp-first: RFC-WF-0015

#agents #architecture #security #systemdesign

RFC-WF-0015

Policy Packs & Governance Profiles (PPGP)

Status: Draft Standard
Version: 1.0.0
Date: 20 Nov 2025
Category: Standards Track
Author: FullAgenticStack Initiative
Dependencies: RFC-WF-0003 (CCP), RFC-WF-0004 (ACSM), RFC-WF-0005 (CRCD), RFC-WF-0006 (EAS), RFC-WF-0007 (OoC), RFC-WF-0008 (RCP), RFC-WF-0010 (IDS)
License: Open Specification (Public, Royalty-Free)

Abstract

This document specifies Policy Packs & Governance Profiles (PPGP) for WhatsApp-first systems. PPGP defines a standard mechanism to declare, version, distribute, and enforce policy bundles that govern command confirmations, step-up verification, redaction rules, idempotency windows, recovery permissions, and observability detail levels. PPGP enables consistent governance across services and tenants by binding policies to CRCD commands/capabilities and producing auditable enforcement via EAS.

Index Terms— policy-as-code, governance profiles, confirmation policy, step-up policy, redaction, idempotency windows, recovery authorization, observability controls.

I. Introduction

WhatsApp-first systems require consistent enforcement of safety and security rules across many commands and services. Hardcoding these rules per service leads to drift and unverifiable behavior. PPGP introduces policy packs (portable governance bundles) and profiles (named configurations like “Basic”, “Strong”, “Operational”) that can be attached to tenants, environments, or command groups.

PPGP complements CRCD by providing the actual policy definitions referenced by confirmation_policy_id, step_up_policy_id, redaction constraints, and IDS TTLs.

II. Scope

PPGP specifies:

Policy pack format and required metadata
Policy types (confirmation, step-up, redaction, idempotency, recovery, OoC detail)
How policies bind to commands/capabilities (via CRCD selectors)
Versioning and deprecation rules for policies
Evidence requirements to prove policy enforcement (EAS)
Suggested governance profiles (non-normative examples)

PPGP does not mandate a particular engine; it defines interoperable policy documents and enforcement obligations.

III. Normative Language

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

IV. Definitions

Policy Pack: A versioned bundle of policies that can be applied to a system/tenant.
Governance Profile: A named composition of policy settings (e.g., “WFS-Basic”, “WFS-Strong”).
Policy Selector: A rule that targets commands/capabilities by name, tags, domain, or safety class.
Enforcement Proof: Evidence fields showing which policy was applied and why.

V. Design Goals

PPGP MUST ensure:

G1. Consistency: policies are centralized and versioned
G2. Traceability: enforcement decisions are provable via evidence
G3. Portability: policy packs can be reused across deployments
G4. Safety: default policies are deny-by-default for high-impact actions
G5. Extensibility: new policies can be added without breaking old packs

VI. Policy Pack Format

A. Required Fields

A policy pack MUST include:

pack_id (stable id)
pack_version (SemVer)
applies_to (system_id pattern or *)
profiles[] (at least one)
policies (definitions keyed by policy_id)
selectors[] (binding rules)
generated_at, author (recommended)

B. Example (YAML)

pack_id: "wfs-core-policies"
pack_version: "1.0.0"
applies_to: "*"
profiles:
  - profile_id: "WFS-Basic"
    description: "Minimum safe governance"
    enabled_policies:
      confirmation: "confirm.std"
      step_up: "stepup.admin"
      redaction: "redact.default"
      idempotency: "idem.default"
      recovery: "recovery.default"
      ooc_detail: "ooc.summary_first"
policies:
  confirmation:
    confirm.std:
      destructive_method: "token"
      mutation_method: "explicit_phrase"
      preview_required: true
  step_up:
    stepup.admin:
      required_for_safety: ["S3", "R3"]
      freshness_seconds: 600
  redaction:
    redact.default:
      pii: "mask"
      secrets: "drop"
      internal_topology: "drop"
  idempotency:
    idem.default:
      default_ttl_seconds: 86400
      financial_ttl_seconds: 604800
  recovery:
    recovery.default:
      allow_retry_for_actor: true
      allow_compensate_scopes: ["admin.recovery.compensate"]
  ooc_detail:
    ooc.summary_first:
      max_detail_level: 2
selectors:
  - selector_id: "destructive-default"
    match:
      safety_class: ["S2"]
    bind:
      confirmation_policy_id: "confirm.std"
      idempotency_policy_id: "idem.default"
  - selector_id: "admin-high-impact"
    match:
      safety_class: ["S3"]
    bind:
      confirmation_policy_id: "confirm.std"
      step_up_policy_id: "stepup.admin"
      redaction_policy_id: "redact.default"

VII. Policy Types (Normative Minimum Set)

An implementation MUST support the following policy types:

Confirmation Policy (CCP)
Step-up Policy (ACSM)
Redaction Policy (OoC/EAS outputs)
Idempotency Policy (IDS TTLs, dedupe behavior classes)
Recovery Policy (RCP permissions, allowed actions per risk)
OoC Detail Policy (summary-first + drill-down limits)

Implementations MAY support more, but MUST at least map these.

VIII. Binding Semantics

A. Selector Matching

Selectors MUST support matching by at least:

command_name (exact or pattern)
domain (from CRCD capabilities)
safety_class (S0–S3; and recovery R0–R3)
tags (optional)

B. Precedence Rules

If multiple selectors match the same command:

precedence MUST be deterministic
packs MUST define precedence ordering (e.g., highest specificity wins)
conflicts MUST be detectable and auditable

C. Deny-by-Default for High Impact

If a command is S3 or R3 and no step-up policy is bound, the system MUST treat this as a misconfiguration and MUST NOT execute (fail closed).

IX. Runtime Enforcement and Evidence

A. Policy Resolution Proof

For every mutating command, the system MUST record in evidence:

which policy pack + version was active
which profile was active
which selectors matched
which policy ids were applied (confirmation/step-up/redaction/idem/recovery)

This can be recorded in EAS security.authz.policy_id and/or a dedicated policy block.

B. Drift Detection

The system SHOULD provide an OoC query to report current active policy pack/profile versions, enabling operators to confirm governance without dashboards.

X. Versioning and Deprecation

Policy packs MUST use SemVer.
Breaking changes (e.g., changing default confirmation method for S2) MUST bump MAJOR.
Deprecated policies MUST include deprecated_since and optional replacement_policy_id.

XI. Relationship to Other RFCs

CCP (0003): confirmation policies are referenced and enforced.
ACSM (0004): step-up policies and trust freshness enforced.
CRCD (0005): commands/capabilities reference policy ids and safety classes.
EAS (0006): provides the evidence substrate for enforcement proof.
OoC (0007): redaction/detail policies govern what can be shown conversationally.
RCP (0008): recovery policies govern who can do what and how.
IDS (0010): idempotency policies define TTLs and dedupe constraints.

XII. Security Considerations

Policy packs are high-value configuration. Implementations MUST:

restrict who can update policy packs (admin scopes + step-up)
audit policy updates as evidence artifacts
support rollback of policy pack versions (via governed recovery)
prevent policy injection through untrusted channels

XIII. Conclusion

PPGP turns “security and safety rules” into versioned, portable, auditable governance. By standardizing policy packs, selectors, precedence, and enforcement proof, WhatsApp-first systems can scale across services and tenants without drifting into inconsistent or unverifiable behavior.

References

[1] RFC-WF-0003, Conversational Command Protocol (CCP).
[2] RFC-WF-0004, Administrative Command Security Model (ACSM).
[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-0010, Idempotency & Delivery Semantics (IDS).

Concepts and Technologies

Policy-as-code, governance profiles, selector-based policy binding, confirmation/step-up/redaction policies, idempotency TTL policies, recovery permission policies, deterministic precedence, evidence-backed enforcement, drift detection.

DEV Community