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 error code hierarchy and can 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 error code. It provides the highest level of categorization, identifying which part of your 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
- Hierarchical organization: Enable grouping of related errors
- Flexible categorization: Support different organizational approaches
- Human-readable: PascalCase for clarity
- Concise: Maximum 16 characters
- Searchable: Easy filtering by component (e.g.,
E.Auth.*)
2. Purpose and Role#
2.1 What is a Component?
A Component represents a domain of responsibility in your system. It is the top level of your error taxonomy.
Key characteristics:
- Highest level of categorization
- Groups related errors together
- Enables filtering and monitoring by subsystem
- Reflects your system's architecture or organization
2.2 Component is NOT Just Physical
Components can 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
Choose the structure that makes sense for your system.
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
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 (covers most use cases)
Required: YES (mandatory field)
Position: Second field (after Severity)
3.2 Regex Pattern
^[A-Z][a-zA-Z0-9]{0,15}$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 details.
4. Component Types#
4.1 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 operationsUse when: Your errors map naturally to infrastructure or system resources.
4.2 Logical Modules
Represent conceptual or functional domains within your 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 logicUse when: Your errors map to functional responsibilities rather than physical components.
4.3 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 serviceUse when: You have a service-oriented or microservices architecture.
Note: Keep names concise. NotificationSvc (15 chars) is better than NotificationService (19 chars, exceeds limit).
4.4 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 layerUse when: Your system follows a strict layered architecture and errors map to layers.
4.5 Mixed Approach
You can mix component types! Choose what makes sense for each part of your system.
Example:
Auth - Logical module
Database - Physical subsystem
UserService - Service boundary
Api - Architectural layer
Parser - Logical module
Network - Physical subsystem5. Naming Guidelines#
5.1 DO: Use Clear, Descriptive Names
✓ Auth - Clear purpose
✓ Database - Descriptive
✓ TokenValidator - Specific and clear
✓ PaymentGateway - Understandable
✓ Parser - Standard term5.2 DO: Keep Names Concise
Recommended: 8-12 characters (sweet spot)
✓ Auth (4 chars) - Concise
✓ Database (8 chars) - Good length
✓ Validation (10 chars) - Good length
✓ TokenValidator (14 chars) - Still good
✓ ServiceRegistry (15 chars) - Near limit but OKMaximum: 16 characters (enforced)
✓ ConfigValidator (15 chars) - OK
✓ ConnectionPool (14 chars) - OK
✗ AuthenticationService (21 chars) - Too long!
✗ ConfigurationManager (20 chars) - Too long!5.3 DO: Use Domain-Specific Terminology
Use terms that are familiar to your 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 DO: Be Consistent
Pick a style and stick to it across your codebase:
✓ Consistent:
Auth, Database, Parser, Network, Cache
✗ Inconsistent:
Auth, DB, parser, NetworkLayer, caching5.5 DON'T: Use Overly Generic Names
Avoid names that don't 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 are OK if your system is small and simple.
5.6 DON'T: Include Version Numbers
✗ AuthV2 - Version numbers shouldn't be in error codes
✗ ApiV1 - Use different component name if truly different
✗ Parser2 - Indicates poor naming
✓ Auth - Version-agnostic
✓ Api - Can evolve without renamingRationale: Error codes should be stable. If you need to version, create a new component name that reflects the actual difference (e.g., Auth vs OAuthProvider).
5.7 DON'T: Use Abbreviations (Unless Widely Recognized)
Widely recognized abbreviations are OK:
✓ 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 should be avoided:
✗ AuthZ - Use "Auth" or "Authorization"
✗ PersCtx - Use "PersistenceContext"
✗ UsrMgmt - Use "UserManagement" or "UserService"
✗ TxnProc - Use "Transaction" or "TransactionProcessor"When in doubt: Use the full word or a clearer term.
6. Common Components#
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
Must satisfy:
- Starts with uppercase letter:
[A-Z] - Followed by 0-15 letters or digits:
[a-zA-Z0-9]{0,15} - Total length: 1-16 characters
- PascalCase convention (recommended but not enforced)
- No special characters (no hyphens, underscores, spaces, etc.)
7.2 Validation Examples
Valid:
✓ A (1 char minimum)
✓ Auth (lowercase allowed after first)
✓ Database (mixed case OK)
✓ API (all caps after first OK)
✓ Http2Server (digit allowed)
✓ TokenValidator (14 chars)
✓ ConfigValidator (15 chars)
✓ ABCDEFGHIJKLMNO (16 chars - max length)Invalid:
✗ auth - Must start with uppercase
✗ Auth-Service - No hyphens
✗ Auth_Service - No underscores
✗ Auth Service - No spaces
✗ Auth! - No special characters
✗ 2Auth - Cannot start with digit
✗ AuthenticationService - Too long (21 chars)7.3 Validation Regex
^[A-Z][a-zA-Z0-9]{0,15}$7.4 PascalCase Enforcement
Note: The regex allows any mix of uppercase/lowercase after the first character. However, PascalCase is strongly recommended for readability:
✓ Recommended: Auth, Database, TokenValidator
⚠ Allowed: AUTH, auth, database, TOKENVALIDATORMost implementations should enforce PascalCase via linters or code review.
8. Hash Canonical Form#
8.1 Purpose
To enable case-insensitive lookups and prevent typos from creating phantom error codes, WDP uses uppercase normalization before hashing.
8.2 Display Form vs Hash Form
Display form (PascalCase):
E.Auth.Token.001
E.Database.Connection.021
E.TokenValidator.Parse.003Hash form (UPPERCASE):
E.AUTH.TOKEN.001
E.DATABASE.CONNECTION.021
E.TOKENVALIDATOR.PARSE.0038.3 Normalization Process
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 these 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 → Xy8QzTypo resilience: Users can search for errors without worrying about exact case.
Cross-implementation safety: Even if implementations format slightly differently, hashes match.
8.5 Implementation Note
Implementations SHOULD:
- Display error codes in PascalCase
- Enforce PascalCase via validation/linters
- Convert to uppercase only when computing hash
- Never store or transmit the uppercase form (use display form)
9. Implementation Guide#
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#
10.1 Complete Error 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
| Property | Value |
|---|---|
| Format | PascalCase |
| Regex | ^[A-Z][a-zA-Z0-9]{0,15}$ |
| Length | 1-16 characters (recommended: 8-12) |
| Position | Second field |
| Required | YES |
Component Types
| Type | Examples |
|---|---|
| Physical | Database, Network, FileSystem, Cache |
| Logical | Auth, Validation, Parser, BusinessLogic |
| Service | UserService, OrderService, PaymentGateway |
| Layer | Api, Domain, Infrastructure |
Hash Normalization
Display: E.Auth.Token.001
Hash: E.AUTH.TOKEN.001 (uppercase)Appendix B: References#
- STRUCTURE.md - Overview of WDP 5-part structure
- 1-SEVERITY.md - Part 1: Severity field specification
- 3-PRIMARY.md - Part 3: Primary field specification
- 4-SEQUENCE.md - Part 4: Sequence field specification
- 5-COMPACT-IDS.md - Part 5: Compact ID (hash) specification