Core Part2 of 5
Version0.1.0-draft
Last Updated2025-11-30
StatusDraft
TypeNORMATIVE (Core)

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 5

This 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: Transaction

3. 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

Regex
^[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 operations

Use 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 logic

Use 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 service

Use 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 layer

Use 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 subsystem

5. Naming Guidelines#

5.1 DO: Use Clear, Descriptive Names

✓ Auth              - Clear purpose
✓ Database          - Descriptive
✓ TokenValidator    - Specific and clear
✓ PaymentGateway    - Understandable
✓ Parser            - Standard term

5.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 OK

Maximum: 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 processing

5.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, caching

5.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 renaming

Rationale: 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 understood

Obscure 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/decryption

6.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 mapping

6.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 communication

6.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 execution

6.5 Business & Domain

BusinessLogic     - Core business logic
Domain            - Domain layer
Order             - Order management
Payment           - Payment processing
Inventory         - Inventory management
Fulfillment       - Order fulfillment
Catalog           - Product catalog

6.6 System & Infrastructure

Config            - Configuration management
Logger            - Logging subsystem
Monitoring        - Monitoring/metrics
Scheduler         - Task scheduling
Background        - Background job processing
Migration         - Database migration
Deployment        - Deployment operations

6.7 User Interface

UI                - User interface
Frontend          - Frontend application
Api               - API/presentation layer
Controller        - MVC controller
View              - View/rendering
Form              - Form handling

7. Validation Rules#

7.1 Format Validation

Must satisfy:

  1. Starts with uppercase letter: [A-Z]
  2. Followed by 0-15 letters or digits: [a-zA-Z0-9]{0,15}
  3. Total length: 1-16 characters
  4. PascalCase convention (recommended but not enforced)
  5. 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

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, TOKENVALIDATOR

Most 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.003

Hash form (UPPERCASE):

E.AUTH.TOKEN.001
E.DATABASE.CONNECTION.021
E.TOKENVALIDATOR.PARSE.003

8.3 Normalization Process

Before computing the compact ID hash:

  1. Display: E.Auth.Token.001
  2. Normalize: E.AUTH.TOKEN.001 (convert to uppercase)
  3. Hash: Compute hash from normalized form
  4. 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 → Xy8Qz

Typo 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

Rust
#[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

Python
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

Typescript
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 disconnected

Logical 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 missing

Service 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 unavailable

Layer Components:

E.Api.Request.003             - Invalid API request
E.Domain.Validation.003       - Domain validation failed
E.Persistence.Save.027        - Persistence layer unavailable

10.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 expired

Compiler/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 failed

Microservices:

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 down

Appendix A: Quick Reference#

Component Format

PropertyValue
FormatPascalCase
Regex^[A-Z][a-zA-Z0-9]{0,15}$
Length1-16 characters (recommended: 8-12)
PositionSecond field
RequiredYES

Component Types

TypeExamples
PhysicalDatabase, Network, FileSystem, Cache
LogicalAuth, Validation, Parser, BusinessLogic
ServiceUserService, OrderService, PaymentGateway
LayerApi, 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

End of Component Field Specification