RFC-WF-0032
Domain Modeling & Safety Class Guidelines (DMSG)
Status: Draft Standard
Version: 1.0.0
Date: 20 Nov 2025
Category: Standards Track
Author: FullAgenticStack Initiative
Dependencies: RFC-WF-0005 (CRCD), RFC-WF-0003 (CCP), RFC-WF-0010 (IDS), RFC-WF-0015 (PPGP), RFC-WF-0018 (SMCL), RFC-WF-0022 (HAPF)
License: Open Specification (Public, Royalty-Free)
Abstract
This document specifies Domain Modeling & Safety Class Guidelines (DMSG) for WhatsApp-first systems. DMSG defines normative guidelines for modeling domains (capabilities, commands, entities) and assigning safety classes and idempotency classes consistently. DMSG provides rules for classifying operations as read-only, safe mutation, destructive, or admin-high-impact, and for mapping those classes to confirmation, approval, step-up, and retention behaviors. The objective is to prevent inconsistent risk classification across services and to make governance policies (PPGP/HAPF) predictable and auditable.
Index Terms— domain modeling, safety classes, risk classification, destructive actions, approvals, idempotency classes, governance mapping.
I. Introduction
Most failures in “chat-operated systems” don’t happen because protocols don’t exist—they happen because risk classification drifts. One team labels “refund” as a normal mutation, another treats it as high impact. One command is idempotent, another isn’t. Approvals become inconsistent, audits become meaningless.
DMSG standardizes how to model capabilities and commands and how to classify them into safety and idempotency classes in a way that is consistent, policy-bindable, and certifiable.
II. Scope
DMSG specifies:
- Domain decomposition guidelines (capability and command boundaries)
- Safety class assignment rules (S0–S3; R0–R3 alignment)
- Idempotency class assignment rules (I0–I3)
- Mapping guidance from safety/idempotency to CCP/ACSM/HAPF/PPGP behaviors
- Required CRCD declaration fields and checks
DMSG is a guideline-heavy RFC but includes normative minimum constraints for classification consistency.
III. Normative Language
MUST, MUST NOT, SHOULD, SHOULD NOT, MAY are normative.
IV. Definitions
Entity: A domain object whose state is meaningful (Order, Customer, Invoice).
Capability: A user-visible function producing value or mutating state.
Command: An executable operation tied to a capability.
Safety Class: Risk category determining governance gates.
Idempotency Class: Idempotency category determining dedupe/outcome replay behavior.
V. Design Goals
DMSG MUST ensure:
- G1. Consistency: same operation types receive consistent classes across domains.
- G2. Governability: classes map deterministically to policies (PPGP/HAPF).
- G3. Auditability: classification is declared in CRCD and evidenced in execution.
- G4. Safety: high-impact actions receive stronger gates by default.
- G5. Idempotency correctness: mutations are not mislabeled as idempotent when they aren’t.
VI. Domain Modeling Guidelines (Normative Minimum)
A. Capability Boundaries
A capability SHOULD be defined around a user-meaningful outcome, not around internal services.
Capabilities MUST NOT be so broad that a single command can produce unpredictable multi-entity effects without explicit declaration (use workflow plans or multiple commands).
B. Command Granularity
Commands SHOULD represent a single intent with explicit target, e.g.:
Order.Cancel(order_id)Payment.Refund(payment_id, amount)Admin.ScopeGrant(user_id, scope)
Commands MUST declare entity/action/target in CRCD.
VII. Safety Classes (Normative)
A. Minimum Safety Class Set
Commands MUST be assigned one of:
- S0 — Read-only: no persistent mutation
- S1 — Safe Mutation: low-impact, reversible, limited blast radius
- S2 — Destructive: delete/cancel/revoke/reset-like, irreversible or high-risk
- S3 — Admin High-Impact: scopes, secrets, billing, global policies, recovery resets
B. Classification Rules
Rule S0
If mutates_state=false → MUST be S0.
Rule S2
If operation includes any of:
- delete, revoke, reset, cancel, void, purge
- bulk actions affecting multiple resources
- irreversible financial effect (capture, payout) unless strictly reversible by policy
→ MUST be at least S2.
Rule S3
If operation affects:
- authorization (roles/scopes/delegations)
- secrets/credentials/integrations
- billing/payment routing/pricing rules
- global policies/feature flags impacting multiple users/tenants
- recovery reset or system-mode toggles (lockdown)
→ MUST be S3.
Rule S1
All remaining mutations default to S1 unless a rule escalates them.
C. Soft Delete Guidance
Soft delete MUST be classified as S2 unless the system can prove (and evidence) that it is low-impact, fully reversible, and does not trigger downstream destructive semantics. Default is S2.
VIII. Idempotency Classes (Normative)
Commands MUST be assigned one of:
- I0 — Read-only
- I1 — Strict Idempotent Mutation
- I2 — Windowed Idempotent Mutation
- I3 — External Side-Effect Shielded
A. Rules
- Any mutation MUST be at least I1 unless explicitly justified.
- If the command triggers external non-idempotent effects and cannot pass idempotency keys → MUST be I3.
- If the command is safe only within a window (e.g., “send reminder”) → MAY be I2 with declared TTL.
- Mislabeling a non-idempotent mutation as I1 is a critical compliance failure.
IX. Governance Mapping (Normative Expectations)
A. CCP Confirmation
- S1 MUST require confirmation (standard).
- S2 MUST require strengthened confirmation.
- S3 MUST require strengthened confirmation AND step-up (ACSM).
B. HAPF Approval
- S3 and R3 MUST be approval-capable (policy may require).
- S2 SHOULD be approval-capable (Strong/Operational profiles).
C. IDS TTL Guidance
- Financial/irreversible commands SHOULD have longer dedupe TTLs.
- Bulk or destructive commands SHOULD have long TTLs to prevent repeated effects.
D. Evidence Requirements
Evidence MUST record the command’s safety class and idempotency class (directly or via registry_ref binding) to enable audit verification.
X. CRCD Declaration Requirements
CRCD MUST include for each command:
-
safety_class(S0–S3) -
idempotency_class(I0–I3) - required scope(s) and step-up policy refs where applicable
- confirmation policy id
- approval policy id (if used)
Auditors MUST treat missing classification as fail-closed for S2/S3 candidates (i.e., if it looks destructive/admin, lack of declaration is a failure).
XI. Conformance and Audit Checks
CATS/RCMC SHOULD include checks ensuring:
- every command has explicit safety/idempotency class
- S2/S3 commands have required confirmation/step-up bindings
- I3 commands declare shielding strategy
- soft delete classified as S2 unless justified
XII. Security Considerations
Incorrect classification is a security bug: it enables bypass of confirmation/step-up/approval or weak TTL. Implementations MUST treat classification changes as high-impact configuration changes requiring admin control and evidence.
XIII. Conclusion
DMSG standardizes how WhatsApp-first systems model domains and classify risk and idempotency. This makes governance predictable, audits meaningful, and operations safer—especially in systems that rely on conversation and agents to trigger real-world effects.
References
[1] RFC-WF-0005, Command Registry & Capability Declaration (CRCD).
[2] RFC-WF-0003, Conversational Command Protocol (CCP).
[3] RFC-WF-0010, Idempotency & Delivery Semantics (IDS).
[4] RFC-WF-0015, Policy Packs & Governance Profiles (PPGP).
[5] RFC-WF-0018, State Model & Command Lifecycle (SMCL).
[6] RFC-WF-0022, Human-in-the-Loop Profiles & Approval Flows (HAPF).
Concepts and Technologies
Domain-driven capability boundaries, safety classes (S0–S3), idempotency classes (I0–I3), governance mapping to confirmation/step-up/approval, soft delete risk classification, CRCD-declared risk semantics, auditability of classification.
Top comments (0)