Architectural Refactor: Separate Safety Features from Safety Levels

[avrabe]

Problem Statement

The current WRT feature system creates architectural confusion by mixing:

• Allocation strategies (std/alloc/no_std)
• Safety levels (asil-b, asil-c, etc.)
• Safety standards (implied automotive-only)

This prevents users from clearly specifying safety requirements across different domains and creates qualification issues where std library cannot be used for most safety-critical levels.

Current Problematic Patterns

# wrt-component/Cargo.toml - PROBLEMATIC
wrt-foundation = { features = ["asil-b", "alloc"] }

# wrt-foundation/Cargo.toml - PROBLEMATIC  
asil-b = ["runtime-bounds-checking", "basic-monitoring", "bounded-collections"]

User Experience Problem

Users cannot clearly express:

• "I want automotive ASIL-D compliance"
• "I want aerospace DO-178C DAL-A compliance"
• "I want medical IEC 62304 Class C compliance"

Proposed Solution: Four-Layer Safety Architecture

Layer 1: Memory Management Strategy

Certification-qualified allocation strategies:

• `static-allocation` - Pure deterministic (ASIL-D, DAL-A, SIL-4, Class C)
• `bounded-allocation` - Bounded deterministic (ASIL-C, DAL-B, SIL-3, Class B)
• `managed-allocation` - Managed dynamic (ASIL-A/B, DAL-D, SIL-1/2, Class A)
• `std-allocation` - Unqualified (QM, DAL-E only)

Layer 2: Safety Feature Capabilities

Composable safety mechanisms:

• Memory: `compile-time-capacity-limits`, `runtime-bounds-checking`, `memory-budget-enforcement`
• Execution: `control-flow-integrity`, `deterministic-timing`, `execution-monitoring`
• Data: `redundant-computation`, `error-detection-codes`, `checksums-verification`
• Verification: `formal-verification-required`, `mathematical-proofs`, `coverage-analysis`
• Isolation: `memory-isolation`, `process-isolation`, `hardware-isolation`

Layer 3: Safety Standards

International standard compliance:

• `iso-26262` (Automotive), `do-178c` (Aerospace), `iec-61508` (Industrial)
• `iec-62304` (Medical), `en-50128` (Railway), `iso-25119` (Agricultural)

Layer 4: Safety Integrity Levels

Standard-specific graduated requirements:

• ISO 26262: `qm`, `asil-a`, `asil-b`, `asil-c`, `asil-d`
• DO-178C: `dal-e`, `dal-d`, `dal-c`, `dal-b`, `dal-a`
• IEC 61508: `sil-1`, `sil-2`, `sil-3`, `sil-4`
• IEC 62304: `class-a`, `class-b`, `class-c`

Expected Benefits

For Users

# Clear automotive ASIL-D specification
features = [\"iso-26262\", \"asil-d\"]  # Automatically includes static-allocation, mathematical-proofs, etc.

# Clear aerospace DAL-A specification  
features = [\"do-178c\", \"dal-a\"]     # Automatically includes static-allocation, coverage-analysis, etc.

# Clear medical Class C specification
features = [\"iec-62304\", \"class-c\"] # Automatically includes bounded-allocation, redundant-computation, etc.

For Architecture

• Clean separation of concerns: Implementation vs safety vs standards vs levels
• Cross-domain compatibility: Support 6 international safety standards
• Qualification support: No unqualified std library in safety-critical paths
• Composable features: Granular control over safety mechanisms
• Certification evidence: Clear traceability to safety requirements

Implementation Strategy

This will be implemented through multiple phases:

1. Phase 1: Core architecture refactor (wrt-foundation)
2. Phase 2: Dependent crates cleanup (wrt-component, wrt-runtime, etc.)
3. Phase 3: Enhanced type system integration
4. Phase 4: Validation and qualification evidence

Acceptance Criteria

• User can specify `features = ["iso-26262", "asil-d"]` without implementation concerns
• User can specify `features = ["do-178c", "dal-a"]` for aerospace applications
• No `std` library dependencies in safety-critical feature combinations
• All existing ASIL compliance tests continue to pass
• Clear documentation of safety qualification constraints
• Build matrix validates all standard/level combinations

Risk Assessment

• Breaking changes: Existing feature usage will need updates
• Qualification impact: Must ensure safety certification is not compromised
• Complexity: Four-layer architecture requires careful coordination
• Testing scope: Combinatorial explosion of feature combinations

Migration Strategy

• Phase 1: Add new features alongside existing (non-breaking)
• Phase 2: Deprecate old mixed features with warnings
• Phase 3: Remove deprecated features in next major version
• Documentation: Provide clear migration guide for each crate