DEV Community

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

Posted on

FullAgenticStack WhatsApp-first: RFC-WF-0026

#webdev #programming #opensource #rfc

RFC-WF-0026

Specification Governance & RFC Process (SGRP)

Status: Draft Standard
Version: 1.0.0
Date: 20 Nov 2025
Category: Standards Track
Author: FullAgenticStack Initiative
Dependencies: RFC-WF-0001 (WFCS), RFC-WF-0021 (SECR), RFC-WF-0016 (RCMC), RFC-WF-0011 (CATS)
License: Open Specification (Public, Royalty-Free)

Abstract

This document specifies Specification Governance & RFC Process (SGRP) for the WhatsApp-first Specification. SGRP defines how RFCs are proposed, reviewed, accepted, versioned, deprecated, and published—ensuring the specification evolves with clear accountability, compatibility guarantees, and testable controls. SGRP standardizes the lifecycle of RFC documents, the registry of canonical identifiers, the mapping to compliance controls (RCMC), and the requirement that normative changes are accompanied by conformance tests (TVRS) and audit updates (CATS).

Index Terms— RFC process, governance, standards evolution, versioning, deprecation, conformance requirements, specification management.

I. Introduction

Specs die when they become either (a) rigid and irrelevant, or (b) chaotic and untestable. WhatsApp-first aims to be a living specification, but one that remains auditable and implementable. SGRP defines a governance process that:

  • prevents incompatible drift
  • forces testability
  • makes compliance and certification meaningful
  • keeps the ecosystem toolable (CATS/RCMC/TVRS)

II. Scope

SGRP specifies:

  • RFC lifecycle states and transitions
  • Required structure of an RFC (metadata + normative sections)
  • Review/acceptance rules and required artifacts
  • Versioning rules for RFCs and the overall spec
  • Control mapping obligations (RCMC) for normative requirements
  • Conformance test obligations (TVRS) and audit updates (CATS)
  • Deprecation and supersedence rules
  • Publication/discovery recommendations (WKD)

SGRP does not define legal entity structure; it defines process obligations.

III. Normative Language

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

IV. Definitions

RFC: A document specifying requirements or guidelines within the WhatsApp-first Specification.
Normative Change: A change affecting MUST/SHOULD/MAY requirements or compliance outcomes.
Control Mapping: The mapping from RFC clauses to control IDs (RCMC).
Superseded RFC: An RFC replaced by a newer RFC or a newer major version.

V. RFC Lifecycle States

Each RFC MUST have one lifecycle state:

  • Draft: under active development
  • Proposed Standard: ready for review; stable enough for implementers
  • Accepted Standard: approved; normative for compliance
  • Deprecated: still valid but discouraged; replacement exists
  • Obsoleted: no longer valid; replaced and not to be used

Transitions MUST be recorded (e.g., in Git history + release notes).

VI. RFC Structure Requirements

Every RFC MUST include:

  • Header metadata (standardized)
  • Abstract
  • Scope
  • Normative language section
  • Definitions (as needed)
  • Requirements (MUST/SHOULD)
  • Security considerations
  • Relationship to other RFCs
  • References
  • Concepts and technologies

Normative requirements MUST be written using RFC 2119-style keywords.

VII. Identifier Governance

A. RFC ID Registry

RFC IDs MUST be unique and stable. Reuse of an RFC number is prohibited.

B. Acronym Registry

RFCs SHOULD register acronyms to avoid collisions.

C. Canonical Slug Rules

Each RFC MUST have a canonical slug for URLs and discovery documents, e.g.:

  • rfc-wf-0001-wfcs
  • rfc-wf-0010-ids

VIII. Versioning Policy

A. RFC Versioning

Each RFC MUST use SemVer:

  • MAJOR: breaking changes to requirements or compliance outcomes
  • MINOR: new backward-compatible requirements (may add controls)
  • PATCH: clarifications, examples, non-breaking fixes

B. Spec Release Versioning

The overall WhatsApp-first Specification SHOULD publish release versions bundling RFC versions, e.g.:

  • WFS Spec 1.0.0 → pinned set of RFC versions
  • WFS Spec 1.1.0 → additions and clarifications
  • WFS Spec 2.0.0 → breaking changes

IX. Normative Change Requirements

Any normative change MUST include:

  1. Updated RFC text
  2. Updated control mapping (RCMC) indicating impacted controls
  3. Updated or new test vectors (TVRS) demonstrating conformance behavior
  4. Updated audit rules (CATS) where applicable
  5. Migration notes (if change is breaking or behaviorally significant)

Normative changes MUST NOT be merged without these artifacts in place.

X. Review and Acceptance Process

A. Minimum Review

A Proposed Standard MUST undergo review for:

  • internal consistency (no contradictions with other RFCs)
  • testability (can be audited)
  • security implications
  • compatibility (SECR implications)

B. Acceptance Criteria

An RFC may be marked Accepted Standard when:

  • control mappings exist (RCMC)
  • conformance scenarios exist (TVRS) for runtime-relevant requirements
  • reference implementations (optional) or implementation notes exist
  • versioning and migration guidance is present

C. Dissent and Alternatives

If multiple design options exist, the RFC SHOULD record alternatives and rationale succinctly.

XI. Deprecation and Obsolescence

A. Deprecation

Deprecated RFCs MUST:

  • indicate replacement RFC(s)
  • specify deprecation date and target removal version
  • maintain compatibility during a deprecation window

B. Obsolete

Obsoleted RFCs MUST NOT be used for new compliance claims.

XII. Publication and Distribution

RFCs SHOULD be published:

  • in a public repository
  • in rendered form (Markdown → site)
  • with a discovery index (via WKD or equivalent)

A canonical index SHOULD list:

  • RFC ID, title, status, version
  • dependencies
  • last updated date
  • controls impacted

XIII. Relationship to Compliance and Certification

RCMC/CATS are normative companions:

  • Compliance claims MUST reference a spec release and RCMC version.
  • Certification attestations MUST pin to RFC/control versions to be verifiable.

XIV. Security Considerations

Governance is part of security. A weak RFC process enables silent breaking changes or “policy drift” that undermine auditability. Implementations SHOULD treat governance artifacts (policy packs, registries, controls) as protected configuration, requiring admin scopes and evidence-backed updates.

XV. Conclusion

SGRP defines how the WhatsApp-first Specification evolves without losing rigor. By enforcing versioning discipline, control mappings, conformance tests, and audit tooling updates for normative changes, SGRP keeps the spec implementable, testable, and certifiable—turning “ideas” into a durable engineering standard.

References

[1] RFC-WF-0001, WhatsApp-First Compliance Core (WFCS).
[2] RFC-WF-0021, Schema Extensions & Compatibility Rules (SECR).
[3] RFC-WF-0016, Reference Compliance Matrix & Control IDs (RCMC).
[4] RFC-WF-0011, Compliance Audit Toolkit Spec (CATS).

Concepts and Technologies

RFC lifecycle governance, SemVer for standards, control mapping discipline, conformance-driven specification, deprecation windows, spec release bundling, canonical slug registries, audit/tooling interoperability.

Top comments (0)