WDP Part 2: Component Field Specification
Part 2 of the Waddling Diagnostic Protocol (WDP): the Component field. The component field identifies the system module, service, or domain that produced the diagnostic code.
Abstract#
This document specifies Part 2 of the Waddling Diagnostic Protocol (WDP): the Component field. The component field identifies the system module, service, or domain that produced the diagnostic code. It represents the highest level of categorization in the diagnostic code hierarchy and MAY represent physical subsystems, logical modules, service boundaries, or architectural layers.
Specification Navigation: See STRUCTURE.md for an overview of all WDP specification parts.
Conformance
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
1. Introduction#
1.1 Purpose
The component field is the second part of a WDP diagnostic code. It provides the highest level of categorization, identifying which part of the system produced the diagnostic code.
1.2 Position in Error Code
Complete WDP Structure:
Severity.Component.Primary.Sequence -> CompactID
^ ^ ^ ^ ^
Part 1 Part 2 Part 3 Part 4 Part 5This Document Focus:
Severity.Component.Primary.Sequence -> CompactID
^^^^^^^^^
Part 2: System module or domain (THIS DOCUMENT)Example: E.Auth.Token.001 - The Auth indicates the authentication/authorization component.
1.3 Design Goals
The component field design adheres to the following principles:
- Hierarchical organization: Enable grouping of related diagnostics
- Flexible categorization: Support different organizational approaches
- Human-readable: PascalCase format for clarity
- Concise: Maximum 16 characters
- Searchable: Enable filtering by component (e.g.,
E.Auth.*)
2. Purpose and Role#
2.1 What is a Component?
A Component represents a domain of responsibility within a system. It serves as the top level of the diagnostic taxonomy.
Key characteristics:
- Highest level of categorization
- Groups related diagnostics together
- Enables filtering and monitoring by subsystem
- Reflects the system's architecture or organization
2.2 Component is NOT Just Physical
Components MAY represent various organizational structures:
- Physical subsystem: Database, Network, FileSystem, Cache
- Logical module: Auth, Validation, BusinessLogic, Parser
- Service boundary: UserService, OrderService, PaymentGateway
- Architectural layer: Api, Domain, Infrastructure
Implementations SHOULD choose the structure that best represents their system architecture.
2.3 Relationship to Primary
Components contain Primaries (Part 3), which provide finer-grained classification:
Component: Auth
├─ Primary: Token
├─ Primary: Session
└─ Primary: Permission
Component: Database
├─ Primary: Connection
├─ Primary: Query
└─ Primary: Transaction3. Field Specification#
3.1 Format
The component field MUST conform to the following specification:
| Property | Requirement |
|---|---|
| Naming Convention | PascalCase (UpperCamelCase) |
| Pattern | Starts with uppercase letter, followed by letters and/or digits |
| Character Set | ASCII letters (a-z, A-Z) and digits (0-9) only |
| Maximum Length | 16 characters |
| Recommended Length | 8-12 characters |
| Required | YES (REQUIRED field) |
| Position | Second field (after Severity) |
3.2 Regex Pattern
Implementations MUST use the following regular expression for validation:
^[A-Z][a-zA-Z0-9]{0,15}$Pattern explanation:
^- Start of string[A-Z]- MUST start with uppercase letter[a-zA-Z0-9]{0,15}- Followed by 0-15 letters or digits$- End of string
Total length: 1-16 characters
3.3 Case Sensitivity
Display form: PascalCase (e.g., Auth, TokenValidator)
Hash form: UPPERCASE (e.g., AUTH, TOKENVALIDATOR)
See Section 8: Hash Canonical Form for normalization requirements.
4. Component Types#
This section describes RECOMMENDED component categorization patterns. These patterns are INFORMATIVE; implementations MAY use any organizational structure appropriate to their domain.
4.1 Physical Subsystems
Physical subsystems represent actual system resources or infrastructure components.
Examples:
Database - Database server or layer
Network - Network communication layer
FileSystem - File I/O subsystem
Cache - Caching layer (Redis, Memcached, etc.)
Queue - Message queue (RabbitMQ, Kafka, etc.)
Storage - Object storage (S3, blob storage)
Memory - Memory management
Disk - Disk I/O operationsApplicable when: Diagnostics map naturally to infrastructure or system resources.
4.2 Logical Modules
Logical modules represent conceptual or functional domains within an application.
Examples:
Auth - Authentication/authorization logic
Validation - Input validation logic
BusinessLogic - Core domain logic
Parser - Parsing and syntax analysis
Serializer - Data serialization/deserialization
Transformer - Data transformation
Mapper - Object mapping (ORM, DTO conversion)
Encoder - Encoding/decoding logicApplicable when: Diagnostics map to functional responsibilities rather than physical components.
4.3 Service Boundaries
Service boundaries represent microservices or service-oriented architecture boundaries.
Examples:
UserService - User management service
OrderService - Order processing service
PaymentGateway - Payment integration service
NotificationSvc - Notification service
AuthService - Authentication service
InventoryService - Inventory management
EmailService - Email sending serviceApplicable when: The system follows a service-oriented or microservices architecture.
Note: Names SHOULD be kept concise. NotificationSvc (15 chars) is preferable to NotificationService (19 chars, exceeds limit).
4.4 Architectural Layers
Architectural layers represent layers in a layered architecture pattern.
Examples:
Api - API/presentation layer
Domain - Domain/business logic layer
Infrastructure - Infrastructure layer
Persistence - Data persistence layer
Application - Application service layer
Presentation - UI/presentation layerApplicable when: The system follows a strict layered architecture and diagnostics map to layers.
4.5 Mixed Approach
Implementations MAY mix component types. The organizational structure SHOULD be chosen based on what makes sense for each part of the system.
Example:
Auth - Logical module
Database - Physical subsystem
UserService - Service boundary
Api - Architectural layer
Parser - Logical module
Network - Physical subsystem5. Naming Guidelines#
This section provides RECOMMENDED naming conventions. Adherence to these guidelines is NOT REQUIRED for conformance but is RECOMMENDED for consistency and readability.
5.1 RECOMMENDED: Use Clear, Descriptive Names
Auth - Clear purpose
Database - Descriptive
TokenValidator - Specific and clear
PaymentGateway - Understandable
Parser - Standard term5.2 RECOMMENDED: Keep Names Concise
Recommended length: 8-12 characters
Auth (4 chars)
Database (8 chars)
Validation (10 chars)
TokenValidator (14 chars)
ServiceRegistry (15 chars)Maximum length: 16 characters (enforced)
ConfigValidator (15 chars)
ConnectionPool (14 chars)
AuthenticationService (21 chars) - Too long! (Invalid)
ConfigurationManager (20 chars) - Too long! (Invalid)5.3 RECOMMENDED: Use Domain-Specific Terminology
Implementations SHOULD use terms that are familiar to the team and domain:
Auth - Widely understood in web development
Catalog - Makes sense for e-commerce
Fulfillment - E-commerce/logistics term
Ledger - Financial/accounting term
Parser - Compiler/language processing5.4 RECOMMENDED: Be Consistent
Implementations SHOULD adopt a consistent naming style across the codebase:
Consistent (RECOMMENDED):
Auth, Database, Parser, Network, CacheInconsistent (NOT RECOMMENDED):
Auth, DB, parser, NetworkLayer, caching5.5 NOT RECOMMENDED: Overly Generic Names
The following names SHOULD be avoided as they do not convey specific meaning:
Module - Too generic
System - Too vague
Error - Meaningless (everything is an error)
Handler - What does it handle?
Manager - What does it manage?
Service - Too generic (which service?)Exception: Generic names MAY be acceptable for small or simple systems.
5.6 NOT RECOMMENDED: Version Numbers
Component names SHOULD NOT include version numbers:
AuthV2 - Version numbers shouldn't be in error codes
ApiV1 - Use different component name if truly different
Parser2 - Indicates poor naming
Valid examples:
Auth - Version-agnostic
Api - Can evolve without renamingRationale: Diagnostic codes SHOULD be stable. If versioning is required, implementations SHOULD create a new component name that reflects the actual difference (e.g., Auth vs OAuthProvider).
5.7 NOT RECOMMENDED: Obscure Abbreviations
Abbreviations SHOULD only be used when widely recognized.
Widely recognized abbreviations:
HTTP - Universally recognized
API - Widely understood
JWT - Standard in auth context
DB - Commonly used (though "Database" is better)
IO - Standard abbreviation
UI - Widely understoodObscure or domain-specific abbreviations (NOT RECOMMENDED):
AuthZ - Use "Auth" or "Authorization"
PersCtx - Use "PersistenceContext"
UsrMgmt - Use "UserManagement" or "UserService"
TxnProc - Use "Transaction" or "TransactionProcessor"Guidance: When in doubt, use the full word or a clearer term.
6. Common Components#
This section provides INFORMATIVE examples of common component names organized by domain. These are suggestions; implementations MAY use any names that conform to the format specification.
6.1 Authentication & Authorization
Auth - General authentication/authorization
AuthService - Authentication service
Security - Security operations
Crypto - Cryptographic operations
Encryption - Encryption/decryption6.2 Data & Persistence
Database - Database operations
DB - Database (abbreviated)
Persistence - Data persistence layer
Storage - File/object storage
Cache - Caching layer
Repository - Repository pattern
ORM - Object-relational mapping6.3 Communication & Networking
Network - Network operations
Net - Network (abbreviated)
HTTP - HTTP client/server
API - API layer
Gateway - API gateway or service gateway
Queue - Message queue
EventBus - Event bus
WebSocket - WebSocket communication6.4 Processing & Logic
Parser - Parsing and syntax analysis
Compiler - Compilation
Validator - Validation logic
Validation - Input validation
Transformer - Data transformation
Processor - Data processing
Engine - Processing engine
Workflow - Workflow execution6.5 Business & Domain
BusinessLogic - Core business logic
Domain - Domain layer
Order - Order management
Payment - Payment processing
Inventory - Inventory management
Fulfillment - Order fulfillment
Catalog - Product catalog6.6 System & Infrastructure
Config - Configuration management
Logger - Logging subsystem
Monitoring - Monitoring/metrics
Scheduler - Task scheduling
Background - Background job processing
Migration - Database migration
Deployment - Deployment operations6.7 User Interface
UI - User interface
Frontend - Frontend application
Api - API/presentation layer
Controller - MVC controller
View - View/rendering
Form - Form handling7. Validation Rules#
7.1 Format Validation
A valid component MUST satisfy the following requirements:
- MUST start with uppercase letter:
[A-Z] - MUST be followed by 0-15 letters or digits:
[a-zA-Z0-9]{0,15} - MUST have total length of 1-16 characters
- SHOULD follow PascalCase convention (RECOMMENDED but not enforced)
- MUST NOT contain special characters (no hyphens, underscores, spaces, etc.)
7.2 Validation Examples
Valid (conformant):
A // 1 char minimum - Valid
Auth // lowercase allowed after first - Valid
Database // mixed case allowed - Valid
API // all caps after first allowed - Valid
Http2Server // digit allowed - Valid
TokenValidator // 14 chars - Valid
ConfigValidator // 15 chars - Valid
ABCDEFGHIJKLMNO // 16 chars (maximum length) - ValidInvalid (non-conformant):
auth // MUST start with uppercase - Invalid
Auth-Service // hyphens NOT permitted - Invalid
Auth_Service // underscores NOT permitted - Invalid
Auth Service // spaces NOT permitted - Invalid
Auth! // special characters NOT permitted - Invalid
2Auth // MUST NOT start with digit - Invalid
AuthenticationService // exceeds 16-char maximum (21 chars) - Invalid7.3 Validation Regex
Implementations MUST use the following regular expression:
^[A-Z][a-zA-Z0-9]{0,15}$7.4 PascalCase Enforcement
Note: The regex permits any mix of uppercase/lowercase after the first character. However, PascalCase is RECOMMENDED for readability:
RECOMMENDED: Auth, Database, TokenValidator
Permitted: AUTH, auth, database, TOKENVALIDATORImplementations SHOULD enforce PascalCase via linters or code review.
8. Hash Canonical Form#
8.1 Purpose
To enable case-insensitive lookups and prevent typographical errors from creating phantom diagnostic codes, WDP REQUIRES uppercase normalization before hashing.
8.2 Display Form vs Hash Form
Display form (PascalCase): Used for human-readable output
E.Auth.Token.001
E.Database.Connection.021
E.TokenValidator.Parse.003Hash form (UPPERCASE): Used for compact ID computation
E.AUTH.TOKEN.001
E.DATABASE.CONNECTION.021
E.TOKENVALIDATOR.PARSE.0038.3 Normalization Process
Implementations MUST normalize diagnostic codes to uppercase before computing the compact ID hash:
- Display:
E.Auth.Token.001 - Normalize:
E.AUTH.TOKEN.001(convert to uppercase) - Hash: Compute hash from normalized form
- Compact ID:
Xy8Qz
8.4 Benefits
Case-insensitive lookups:
All of the following MUST produce the same hash:
E.Auth.Token.001 → E.AUTH.TOKEN.001 → Xy8Qz
E.AUTH.TOKEN.001 → E.AUTH.TOKEN.001 → Xy8Qz
e.auth.token.001 → E.AUTH.TOKEN.001 → Xy8Qz
E.auth.Token.001 → E.AUTH.TOKEN.001 → Xy8QzTypographical error resilience: Users MAY search for diagnostics without concern for exact case.
Cross-implementation safety: Even if implementations format slightly differently, hashes MUST match.
8.5 Implementation Requirements
Implementations:
- SHOULD display diagnostic codes in PascalCase
- SHOULD enforce PascalCase via validation/linters
- MUST convert to uppercase only when computing hash
- SHOULD NOT store or transmit the uppercase form (use display form)
9. Implementation Guide#
This section provides RECOMMENDED implementation patterns. Implementations MAY use alternative approaches provided they satisfy the normative requirements in Sections 3, 7, and 8.
9.1 Rust Implementation
#[derive(Debug, Clone, PartialEq, Eq)]
pub struct Component {
name: String,
}
impl Component {
/// Create a new component with validation
pub fn new(name: impl Into<String>) -> Result<Self, ValidationError> {
let name = name.into();
// Validate format
if !Self::is_valid(&name) {
return Err(ValidationError::InvalidComponent(name));
}
Ok(Self { name })
}
/// Validate component format
pub fn is_valid(name: &str) -> bool {
// Regex: ^[A-Z][a-zA-Z0-9]{0,15}$
if name.is_empty() || name.len() > 16 {
return false;
}
let mut chars = name.chars();
// First character must be uppercase letter
if !matches!(chars.next(), Some('A'..='Z')) {
return false;
}
// Remaining characters must be letters or digits
chars.all(|c| c.is_ascii_alphanumeric())
}
/// Get display form (PascalCase)
pub fn as_str(&self) -> &str {
&self.name
}
/// Get hash canonical form (UPPERCASE)
pub fn canonical(&self) -> String {
self.name.to_uppercase()
}
}
impl std::fmt::Display for Component {
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
write!(f, "{}", self.name)
}
}9.2 Python Implementation
import re
class Component:
"""Represents a WDP component field."""
# Validation regex
PATTERN = re.compile(r'^[A-Z][a-zA-Z0-9]{0,15}$')
def __init__(self, name: str):
"""Create a new component with validation."""
if not self.is_valid(name):
raise ValueError(f"Invalid component: {name}")
self.name = name
@staticmethod
def is_valid(name: str) -> bool:
"""Validate component format."""
return bool(Component.PATTERN.match(name))
def __str__(self) -> str:
"""Get display form (PascalCase)."""
return self.name
def canonical(self) -> str:
"""Get hash canonical form (UPPERCASE)."""
return self.name.upper()
def __eq__(self, other) -> bool:
return isinstance(other, Component) and self.name == other.name
def __hash__(self) -> int:
return hash(self.name)9.3 TypeScript Implementation
class Component {
private static readonly PATTERN = /^[A-Z][a-zA-Z0-9]{0,15}$/;
constructor(private readonly name: string) {
if (!Component.isValid(name)) {
throw new Error(`Invalid component: ${name}`);
}
}
static isValid(name: string): boolean {
return Component.PATTERN.test(name);
}
toString(): string {
return this.name;
}
canonical(): string {
return this.name.toUpperCase();
}
equals(other: Component): boolean {
return this.name === other.name;
}
}10. Examples#
This section provides INFORMATIVE examples demonstrating component usage patterns.
10.1 Complete Diagnostic Codes by Component Type
Physical Components:
E.Database.Connection.021 - Database connection failed
E.Network.Connection.028 - Network host unreachable
E.FileSystem.File.021 - File not found
E.Cache.Connection.027 - Cache server unavailable
E.Queue.Connection.029 - Message queue disconnectedLogical Components:
E.Auth.Token.001 - Authentication token missing
E.Validation.Input.003 - Input validation failed
E.Parser.Syntax.003 - Syntax error in input
E.BusinessLogic.Rule.008 - Business rule violation
E.Crypto.Key.001 - Encryption key missingService Components:
E.UserService.Query.021 - User not found
E.OrderService.Create.008 - Order creation denied
E.PaymentGateway.Process.017 - Payment timeout
E.EmailService.Send.027 - Email service unavailableLayer Components:
E.Api.Request.003 - Invalid API request
E.Domain.Validation.003 - Domain validation failed
E.Persistence.Save.027 - Persistence layer unavailable10.2 Real-World Examples
Web Application:
E.Auth.Login.008 - Login denied
E.Api.RateLimit.008 - Rate limit exceeded
E.Database.Query.017 - Query timeout
E.Cache.Get.021 - Cache key not found
E.Session.Expired.018 - Session expiredCompiler/Parser:
E.Lexer.Token.001 - Unexpected token
E.Parser.Syntax.003 - Syntax error
E.Semantic.Type.002 - Type mismatch
E.Codegen.Output.027 - Code generation failedMicroservices:
E.UserService.Auth.008 - User authentication failed
E.OrderService.Create.003 - Invalid order data
E.InventoryService.Stock.026 - Out of stock
E.PaymentGateway.Charge.017 - Payment processing timeout
E.NotificationSvc.Send.027 - Notification service downAppendix A. Quick Reference#
Component Format
Format: PascalCase
Regex: ^[A-Z][a-zA-Z0-9]{0,15}$
Length: 1-16 characters (recommended: 8-12)
Position: Second field
Required: YESComponent Types
Physical: Database, Network, FileSystem, Cache
Logical: Auth, Validation, Parser, BusinessLogic
Service: UserService, OrderService, PaymentGatewayAppendix B. Normative References#
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.