e11y 0.2.0 → 1.1.0

data/docs/use_cases/UC-010-background-job-tracking.md

@@ -72,35 +72,18 @@ end
 
 ## 🎯 Features
 
-> **Implementation:** See [ADR-008: Rails Integration](../ADR-008-rails-integration.md) for complete architecture, including [Section 5: Sidekiq Integration](../ADR-008-rails-integration.md#5-sidekiq-integration), [Section 6: ActiveJob Integration](../ADR-008-rails-integration.md#6-activejob-integration), and [Section 5.3: Job-Scoped Buffer](../ADR-008-rails-integration.md#53-job-scoped-buffer).
+> **Implementation:** See [ADR-008: Rails Integration](../architecture/ADR-008-rails-integration.md) for complete architecture, including [Section 5: Sidekiq Integration](../architecture/ADR-008-rails-integration.md#5-sidekiq-integration), [Section 6: ActiveJob Integration](../architecture/ADR-008-rails-integration.md#6-activejob-integration), and [Section 5.3: Job-Scoped Buffer](../architecture/ADR-008-rails-integration.md#53-job-scoped-buffer).
 
 ### 1. Automatic Instrumentation
 
-**Zero-config for Sidekiq & ActiveJob:**
+**Enable Sidekiq and Active Job integration:**
 ```ruby
 # config/initializers/e11y.rb
 E11y.configure do |config|
-  config.background_jobs do
-    # Auto-instrument Sidekiq
-    sidekiq enabled: true,
-            track_enqueue: true,
-            track_execution: true,
-            track_retries: true
-    
-    # Auto-instrument ActiveJob
-    active_job enabled: true,
-               track_enqueue: true,
-               track_execution: true,
-               track_retries: true
-    
-    # Metrics
-    metrics enabled: true,
-            include_queue_size: true,
-            include_latency: true
-  end
+  config.rails_instrumentation_enabled = true # ActiveJob ASN events (when using Rails)
+  config.sidekiq_enabled = true
+  config.active_job_enabled = true
 end
-
-# That's it! All jobs automatically tracked ✨
 ```
 
 **What gets tracked automatically:**
@@ -204,7 +187,7 @@ end
 
 ### 5. Job-Specific Events
 
-> **Note:** E11y supports **job-scoped buffering** similar to [UC-001: Request-Scoped Debug Buffering](./UC-001-request-scoped-debug-buffering.md). Debug events within a job are buffered and only flushed if the job fails. See [ADR-001 Section 3.4: Request-Scoped Buffer](../ADR-001-architecture.md#34-request-scoped-buffer) for implementation details (same architecture applies to jobs).
+> **Note:** E11y supports **job-scoped buffering** similar to [UC-001: Request-Scoped Debug Buffering](./UC-001-request-scoped-debug-buffering.md). Debug events within a job are buffered and only flushed if the job fails. See [ADR-001 Section 3.4: Request-Scoped Buffer](../architecture/ADR-001-architecture.md#34-request-scoped-buffer) for implementation details (same architecture applies to jobs).
 
 **Emit custom events within jobs:**
 ```ruby
@@ -506,7 +489,7 @@ end
 
 ### 6. Sidekiq Middleware Implementation (C17, C18 Resolutions) ⚠️
 
-> **Reference:** See [ADR-005 §8.3 (C17)](../ADR-005-tracing-context.md#83-background-job-tracing-strategy-c17-resolution) and [ADR-013 §3.6 (C18)](../ADR-013-reliability-error-handling.md#36-event-tracking-in-background-jobs-c18-resolution) for full architecture.
+> **Reference:** See [ADR-005 §8.3 (C17)](../architecture/ADR-005-tracing-context.md#83-background-job-tracing-strategy-c17-resolution) and [ADR-013 §3.6 (C18)](../architecture/ADR-013-reliability-error-handling.md#36-event-tracking-in-background-jobs-c18-resolution) for full architecture.
 
 E11y provides two critical Sidekiq middlewares:
 
@@ -697,7 +680,7 @@ end
 
 ```ruby
 # ❌ BAD: E11y failure fails the job
-config.error_handling.fail_on_error_in_jobs = true
+config.error_handling_fail_on_error_in_jobs = true
 
 # Job fails if Loki is down:
 # - Payment was created successfully
@@ -706,7 +689,7 @@ config.error_handling.fail_on_error_in_jobs = true
 # - Result: Duplicate payments! 💸💸💸
 
 # ✅ GOOD: E11y failure doesn't fail the job
-config.error_handling.fail_on_error_in_jobs = false
+config.error_handling_fail_on_error_in_jobs = false
 
 # Job succeeds even if Loki is down:
 # - Payment created ✅
@@ -720,78 +703,28 @@ config.error_handling.fail_on_error_in_jobs = false
 
 ## 🔧 Configuration
 
-### Full Configuration
+### Full configuration (shipped API)
+
+There is **no** `config.background_jobs` / `sidekiq do` / `active_job do` DSL in the gem. Use boolean flags and the standard error-handling attribute:
 
 ```ruby
 # config/initializers/e11y.rb
 E11y.configure do |config|
-  config.background_jobs do
-    # === SIDEKIQ ===
-    sidekiq do
-      enabled true
-      
-      # What to track
-      track_enqueue true       # When job added to queue
-      track_start true         # When worker picks up job
-      track_success true       # On successful completion
-      track_failure true       # On error
-      track_retry true         # On retry attempts
-      
-      # Trace propagation
-      propagate_trace_id true  # Preserve trace_id from request
-      
-      # Metrics
-      metrics do
-        enabled true
-        include_queue_size true
-        include_latency true
-        include_processing_time true
-      end
-      
-      # Custom job metadata
-      include_metadata [:queue, :retry_count, :scheduled_at, :enqueued_at]
-    end
-    
-    # === ACTIVEJOB ===
-    active_job do
-      enabled true
-      track_enqueue true
-      track_start true
-      track_success true
-      track_failure true
-      track_retry true
-      propagate_trace_id true
-      
-      # ActiveJob-specific
-      include_adapter_name true  # Sidekiq, Resque, etc.
-      include_executions true    # Execution count
-    end
-    
-    # === FILTERING ===
-    # Don't track these jobs (too noisy)
-    ignore_jobs ['HeartbeatJob', 'HealthCheckJob']
-    
-    # Sample high-volume jobs
-    sample_jobs 'FrequentJob' => 0.1  # 10% sampling
-    
-    # === ALERTING ===
-    alert_on do
-      # Alert on job failures
-      failure_rate threshold: 0.05,  # >5% failure rate
-                   window: 5.minutes
-      
-      # Alert on long queue
-      queue_size threshold: 1000,
-                 queue: 'critical'
-      
-      # Alert on high latency
-      queue_latency threshold: 60.seconds,
-                    queue: 'default'
-    end
-  end
+  config.rails_instrumentation_enabled = true # ActiveJob ASN events when using Rails adapter
+
+  config.sidekiq_enabled = true    # Sidekiq client + server middleware
+  config.active_job_enabled = true # ActiveJob::Base (+ ApplicationJob if defined) callbacks
+
+  config.ephemeral_buffer_enabled = true
+  # config.ephemeral_buffer_job_buffer_limit = 500 # optional
+
+  # Job must not fail because E11y could not ship an event (see error-handling docs)
+  # config.error_handling_fail_on_error = true # default; tune per app if needed
 end
 ```
 
+Details: [RAILS_INTEGRATION.md](../RAILS_INTEGRATION.md), `lib/e11y/instruments/sidekiq.rb`, `lib/e11y/instruments/active_job.rb`.
+
 ---
 
 ## 📊 Metrics

data/docs/use_cases/UC-011-rate-limiting.md

@@ -381,7 +381,7 @@ end
 
 ### Layer 4: DLQ Filter Integration (C02 Resolution) ⚠️
 
-> **Reference:** See [ADR-013 §4.6: Rate Limiting × DLQ Filter](../ADR-013-reliability-error-handling.md#46-rate-limiting--dlq-filter-interaction-c02-resolution) for full architecture.
+> **Reference:** See [ADR-013 §4.6: Rate Limiting × DLQ Filter](../architecture/ADR-013-reliability-error-handling.md#46-rate-limiting--dlq-filter-interaction-c02-resolution) for full architecture.
 
 **Problem:** Rate limiting drops events BEFORE they reach DLQ filter. Critical events (e.g., payments) may be lost during traffic spikes, even though DLQ filter says "always save payments".
 
@@ -472,7 +472,7 @@ end
 
 ### Layer 5: Retry Rate Limiting (C06 Resolution) ⚠️
 
-> **Reference:** See [ADR-013 §3.5: Retry Rate Limiting](../ADR-013-reliability-error-handling.md#35-retry-rate-limiting-c06-resolution) for full architecture.
+> **Reference:** See [ADR-013 §3.5: Retry Rate Limiting](../architecture/ADR-013-reliability-error-handling.md#35-retry-rate-limiting-c06-resolution) for full architecture.
 
 **Problem:** Adapter failures trigger retries. If 1000 events fail → 3000 retry attempts (thundering herd) → buffer overflow.
 
@@ -732,130 +732,85 @@ end
 
 ---
 
-## 📊 Implementation with Redis
+## 📊 Implementation: In-Memory Token Bucket
 
-**Production-ready implementation using Redis:**
+**Current implementation uses in-memory token bucket algorithm (no Redis dependency):**
 
 ```ruby
-# lib/e11y/processing/rate_limiter.rb
+# lib/e11y/middleware/rate_limiting.rb
 module E11y
-  module Processing
-    class RateLimiter
-      def initialize(redis: Redis.new)
-        @redis = redis
-        @config = E11y.config.rate_limiting
-      end
-      
-      def allowed?(event)
-        # Check bypass rules first
-        return true if bypassed?(event)
-        
-        # Check global limit
-        return false unless check_global_limit(event)
-        
-        # Check per-event limit
-        return false unless check_per_event_limit(event)
-        
-        # Check per-context limits
-        return false unless check_per_context_limits(event)
-        
-        true
-      end
-      
-      private
-      
-      def check_global_limit(event)
-        key = 'e11y:rate_limit:global'
-        limit = @config.global_limit
-        window = @config.global_window
-        
-        check_limit(key, limit, window)
-      end
-      
-      def check_per_event_limit(event)
-        limit_config = @config.per_event_limits[event.event_name]
-        return true unless limit_config
-        
-        key = "e11y:rate_limit:event:#{event.event_name}"
-        check_limit(key, limit_config[:limit], limit_config[:window])
-      end
-      
-      def check_per_context_limits(event)
-        @config.per_context_limits.all? do |field, limit_config|
-          value = extract_context_value(event, field, limit_config[:extractor])
-          next true unless value
-          
-          key = "e11y:rate_limit:context:#{field}:#{value}"
-          check_limit(key, limit_config[:limit], limit_config[:window])
+  module Middleware
+    class RateLimiting < Base
+      def initialize(app, global_limit: 10_000, per_event_limit: 1_000, window: 1.0)
+        super(app)
+        @global_limit = global_limit
+        @per_event_limit = per_event_limit
+        @window = window
+
+        # Token buckets for rate limiting (in-memory)
+        @global_bucket = TokenBucket.new(
+          capacity: @global_limit,
+          refill_rate: @global_limit,
+          window: @window
+        )
+        @per_event_buckets = Hash.new do |hash, event_name|
+          hash[event_name] = TokenBucket.new(
+            capacity: @per_event_limit,
+            refill_rate: @per_event_limit,
+            window: @window
+          )
         end
+
+        @mutex = Mutex.new
       end
-      
-      def check_limit(key, limit, window)
-        # Sliding window counter using Redis sorted sets
-        now = Time.now.to_f
-        window_start = now - window
-        
-        # Remove old entries (outside window)
-        @redis.zremrangebyscore(key, 0, window_start)
-        
-        # Count current entries
-        current_count = @redis.zcard(key)
-        
-        if current_count < limit
-          # Add new entry
-          @redis.zadd(key, now, "#{now}-#{SecureRandom.hex(8)}")
-          @redis.expire(key, window.to_i + 60)  # TTL = window + buffer
-          true
-        else
-          # Limit exceeded
-          handle_exceeded(key, current_count, limit)
-          false
+
+      def call(event_data)
+        event_name = event_data[:event_name]
+
+        # Check global rate limit
+        unless @global_bucket.allow?
+          handle_rate_limited(event_data, :global)
+          return nil
         end
-      end
-      
-      def handle_exceeded(key, current, limit)
-        # Track metric
-        Yabeda.e11y_internal.rate_limit_hits_total.increment(
-          limit_type: extract_limit_type(key),
-          key: key
-        )
-        
-        # Log warning
-        E11y.logger.warn(
-          "[E11y] Rate limit exceeded: #{key} (#{current}/#{limit})"
-        )
-        
-        # Alert if configured
-        if @config.alert_on_limit
-          alert_rate_limit_exceeded(key, current, limit)
+
+        # Check per-event rate limit
+        per_event_bucket = @mutex.synchronize { @per_event_buckets[event_name] }
+        unless per_event_bucket.allow?
+          handle_rate_limited(event_data, :per_event)
+          return nil
         end
+
+        # Rate limit not exceeded - continue pipeline
+        event_data
       end
-      
-      def bypassed?(event)
-        # Check bypass rules
-        @config.bypass_rules.any? do |rule|
-          case rule[:type]
-          when :event_types
-            rule[:values].include?(event.event_name)
-          when :severities
-            rule[:values].include?(event.severity)
-          when :contexts
-            rule[:values].all? { |k, v| event.context[k] == v }
-          when :custom
-            rule[:condition].call(event)
-          end
-        end
+
+      private
+
+      def handle_rate_limited(event_data, limit_type)
+        # C02 Resolution: Check if event should be saved to DLQ
+        return unless should_save_to_dlq?(event_data)
+
+        save_to_dlq(event_data, limit_type)
       end
     end
   end
 end
 ```
 
+**Why In-Memory Token Bucket?**
+- ✅ **Fast:** No network latency (O(1) operations)
+- ✅ **Simple:** No external dependencies (Redis not required)
+- ✅ **Thread-safe:** Mutex-protected token buckets
+- ✅ **Smooth rate limiting:** Token bucket avoids bursty behavior
+- ⚠️ **Trade-off:** Per-process limits (not shared across instances)
+
+**Note:** In-memory rate limiting is sufficient for most use cases. Each application process maintains its own rate limits, which is appropriate for event tracking workloads.
+
 ---
 
 ## 🔧 Implementation Details
 
-> **Implementation:** See [ADR-006 Section 4.0: Rate Limiting + Retry Policy Resolution](../ADR-006-security-compliance.md#40-rate-limiting--retry-policy-resolution-conflict-14) for detailed architecture.
+> **Implementation:** See [ADR-006 Section 4.0: Rate Limiting + Retry Policy Resolution](../architecture/ADR-006-security-compliance.md#40-rate-limiting--retry-policy-resolution-conflict-14) for detailed architecture.
 
 ### Middleware Flow
 
@@ -980,53 +935,27 @@ end
 
 ---
 
-### Redis-Based Rate Limiting
+### Token Bucket Algorithm
 
-E11y uses **Redis sorted sets** for distributed rate limiting across multiple application instances.
+E11y uses **in-memory token bucket algorithm** for rate limiting.
 
-**Algorithm: Sliding Window Counter**
+**How Token Bucket Works:**
+- Each bucket has a **capacity** (max tokens) and **refill rate** (tokens per second)
+- When event arrives: Check if token available → consume token if yes
+- Tokens refill continuously based on elapsed time
+- Allows burst traffic up to capacity, then smooth rate limiting
 
-```ruby
-def check_limit(key, limit, window)
-  now = Time.now.to_f
-  window_start = now - window
-  
-  # 1. Remove expired entries (outside window)
-  redis.zremrangebyscore(key, 0, window_start)
-  
-  # 2. Count current entries
-  current_count = redis.zcard(key)
-  
-  # 3. Check limit
-  if current_count < limit
-    # Add new entry (score = timestamp, member = unique ID)
-    redis.zadd(key, now, "#{now}-#{SecureRandom.hex(8)}")
-    redis.expire(key, window.to_i + 60)  # TTL cleanup
-    true  # Allowed
-  else
-    false  # Rate limited
-  end
-end
-```
+**Why Token Bucket?**
+- ✅ **Smooth rate limiting:** Avoids bursty behavior
+- ✅ **Burst support:** Allows traffic spikes up to capacity
+- ✅ **Fast:** O(1) operations (no external dependencies)
+- ✅ **Industry standard:** Used by Nginx, AWS API Gateway, Google Cloud
+- ⚠️ **Per-process limits:** Each application instance has separate limits
 
-**Why Sorted Sets?**
-- ✅ **Sliding window:** Accurate counting (no edge cases like fixed window)
-- ✅ **Distributed:** Works across multiple app instances
-- ✅ **Efficient:** O(log N) for add/remove operations
-- ✅ **Automatic cleanup:** Redis TTL handles old entries
-
-**Redis Keys:**
-```ruby
-# Global limit
-"e11y:rate_limit:global"
-
-# Per-event limit
-"e11y:rate_limit:event:payment.retry"
-
-# Per-context limit
-"e11y:rate_limit:context:user_id:user-123"
-"e11y:rate_limit:context:ip_address:192.168.1.100"
-```
+**Memory Usage:**
+- Global bucket: ~100 bytes (single TokenBucket instance)
+- Per-event buckets: ~100 bytes per unique event type (lazy initialization)
+- Example: 100 event types × 100 bytes = ~10KB total
 
 ---
 
@@ -1095,30 +1024,28 @@ end
 # Overhead: ~0.5μs (5% increase)
 ```
 
-**Redis Latency:**
+**In-Memory Performance:**
 ```ruby
-# Redis operations per event (within limit):
-# 1. ZREMRANGEBYSCORE (cleanup)  ~0.1ms
-# 2. ZCARD (count)               ~0.05ms
-# 3. ZADD (add entry)            ~0.05ms
-# 4. EXPIRE (set TTL)            ~0.05ms
-# Total: ~0.25ms per event
+# Token bucket operations per event (within limit):
+# 1. Mutex lock                    ~0.001ms
+# 2. Refill calculation           ~0.001ms
+# 3. Token consumption            ~0.001ms
+# Total: ~0.003ms per event (3000x faster than Redis!)
 
 # When rate limited:
-# 1. ZREMRANGEBYSCORE            ~0.1ms
-# 2. ZCARD                       ~0.05ms
-# Total: ~0.15ms (no write)
+# 1. Mutex lock                    ~0.001ms
+# 2. Refill calculation           ~0.001ms
+# 3. Check tokens (0 available)   ~0.001ms
+# Total: ~0.003ms (no network overhead)
 ```
 
 **Scaling:**
 ```ruby
-# Redis memory usage:
-# - Global limit (10k events/min): ~500KB
-# - Per-event limit (100/min): ~5KB per event type
-# - Per-context limit (1k/min): ~50KB per user
-# 
-# Example: 1000 users × 50KB = 50MB
-# → Acceptable for most deployments
+# Memory usage (in-memory):
+# - Global bucket: ~100 bytes
+# - Per-event bucket: ~100 bytes per unique event type
+# - Example: 100 event types × 100 bytes = ~10KB total
+# → Negligible memory footprint
 ```
 
 ---
@@ -1198,7 +1125,7 @@ end
 
 ## 📊 Self-Monitoring & Metrics
 
-> **Implementation:** See [ADR-006 Section 4: Rate Limiting](../ADR-006-security-compliance.md#4-rate-limiting) for detailed architecture.
+> **Implementation:** See [ADR-006 Section 4: Rate Limiting](../architecture/ADR-006-security-compliance.md#4-rate-limiting) for detailed architecture.
 
 E11y provides comprehensive self-monitoring metrics for rate limiting. These metrics help you understand rate limit behavior, detect attacks, and optimize limits.
 

data/docs/use_cases/UC-012-audit-trail.md

@@ -240,7 +240,7 @@ end
 > - ✅ Separate storage (isolated from app DB)
 > - ✅ Long retention (7-10 years)
 >  
-> **Implementation:** See [ADR-015 §3.3: Audit Event Pipeline Separation](../ADR-015-middleware-order.md#33-audit-event-pipeline-separation-c01-resolution) for full architecture.
+> **Implementation:** See [ADR-015 §3.3: Audit Event Pipeline Separation](../architecture/ADR-015-middleware-order.md#33-audit-event-pipeline-separation-c01-resolution) for full architecture.
 
 ---
 
@@ -424,15 +424,11 @@ Events::UserDeleted.track(
 E11y.configure do |config|
   config.audit_trail do
     # Separate storage for audit events
-    storage adapter: :postgresql,  # OR :s3, :file
+    storage adapter: :postgresql,  # OR :file
             table: 'audit_events',
             read_only: true  # Can't UPDATE/DELETE
     
-    # S3 with object lock (true immutability)
-    # storage adapter: :s3,
-    #         bucket: 'company-audit-trail',
-    #         object_lock: true,  # WORM (Write Once Read Many)
-    #         retention_period: 7.years
+    # Object storage with WORM (external; E11y uses retention_until for archival filtering)
   end
 end
 
@@ -568,14 +564,13 @@ E11y.configure do |config|
     
     # === ARCHIVAL ===
     archive_after 1.year,
-                  to: :s3_glacier,  # Cheaper cold storage
-                  bucket: 'company-audit-archive'
+                  to: :archive,  # Cold storage (external job filters by retention_until)
   end
 end
 
 # How it works:
-# 1. Events stored in hot storage (PostgreSQL/S3)
-# 2. After 1 year → moved to cold storage (Glacier)
+# 1. Events stored in hot storage (PostgreSQL/File)
+# 2. After 1 year → moved to cold storage (archival job filters by retention_until)
 # 3. After retention period → permanently deleted
 # 4. Deletion logged as audit event (audit the audit!)
 ```
@@ -1239,7 +1234,7 @@ end
 
 ## 🔧 Implementation Details
 
-> **Implementation:** See [ADR-006 Section 5: Audit Trail](../ADR-006-security-compliance.md#5-audit-trail) for detailed architecture.
+> **Implementation:** See [ADR-006 Section 5: Audit Trail](../architecture/ADR-006-security-compliance.md#5-audit-trail) for detailed architecture.
 
 ### Audit Middleware Architecture
 
@@ -1554,17 +1549,18 @@ module E11y
 end
 ```
 
-**3. S3 Audit Adapter (Cloud, Object Lock WORM)**
+**3. Object Storage Audit Adapter (conceptual; not in E11y)**
+
+> E11y does not provide an S3/object-storage adapter. For cloud WORM storage, use OTel Collector's object-storage exporter, or an external archival job that filters Loki by `retention_until`. Events carry `retention_until` (ISO8601) for easy filtering.
 
 ```ruby
-# lib/e11y/adapters/s3_audit.rb
+# Conceptual: Object storage with WORM (e.g., S3 Object Lock)
+# E11y does NOT implement this — use external archival
 module E11y
   module Adapters
-    class S3Audit < Base
+    class ObjectStorageAudit < Base  # Conceptual only
       def initialize(config)
         @bucket = config.bucket
-        @s3_client = Aws::S3::Client.new
-        @object_lock = config.object_lock || true
         @retention_days = config.retention_days || 2555  # 7 years
       end
       
@@ -1573,37 +1569,16 @@ module E11y
       end
       
       def write(event_data)
-        object_key = audit_object_key(event_data)
-        
-        @s3_client.put_object(
-          bucket: @bucket,
-          key: object_key,
-          body: event_data.to_json,
-          content_type: 'application/json',
-          
-          # WORM: Object Lock prevents deletion
-          object_lock_mode: 'GOVERNANCE',  # OR 'COMPLIANCE' (stricter)
-          object_lock_retain_until_date: @retention_days.days.from_now,
-          
-          # Metadata for audit
-          metadata: {
-            'event-id' => event_data[:event_id],
-            'event-name' => event_data[:event_name],
-            'signed-at' => event_data[:signed_at],
-            'signature-algorithm' => event_data[:signature_algorithm]
-          }
-        )
+        # Filter by retention_until for archival decisions
+        # object_key = "#{event_data[:retention_until]}/#{event_data[:event_id]}.json"
+        # ... PUT to object storage with WORM ...
       end
       
       private
       
       def audit_object_key(event_data)
-        timestamp = event_data[:timestamp]
-        date = timestamp.to_date
-        hour = timestamp.hour
-        
-        # Partition by date and hour for efficient queries
-        "audit/#{date.strftime('%Y/%m/%d')}/hour=#{hour.to_s.rjust(2, '0')}/#{event_data[:event_id]}.json"
+        ts = Time.parse(event_data[:timestamp])
+        "audit/#{ts.strftime('%Y/%m/%d')}/#{event_data[:event_id]}.json"
       end
     end
   end
@@ -1715,7 +1690,7 @@ end
 
 ## ⚡ Performance Guarantees
 
-> **Implementation:** See [ADR-006 Section 5.2: Cryptographic Signing](../ADR-006-security-compliance.md#52-cryptographic-signing) for detailed architecture.
+> **Implementation:** See [ADR-006 Section 5.2: Cryptographic Signing](../architecture/ADR-006-security-compliance.md#52-cryptographic-signing) for detailed architecture.
 
 E11y audit trail is designed for **high-performance production environments** with strict SLOs. Audit events must not significantly impact application latency.
 
@@ -1880,10 +1855,10 @@ end
 |-----------------|---------------------|------------|----------|
 | **File (append-only)** | 1-2ms | 10,000/sec | Simple, local, fast |
 | **PostgreSQL** | 2-5ms | 5,000/sec | Queryable, ACID |
-| **S3 (Object Lock)** | 10-50ms | 1,000/sec | Cloud, immutable (WORM) |
+| **Object storage (WORM)** | 10-50ms | 1,000/sec | Cloud, immutable (external archival) |
 | **Elasticsearch** | 5-10ms | 3,000/sec | Full-text search |
 
-**Recommendation:** Use **File adapter** for lowest latency, **PostgreSQL** for queryability, **S3** for compliance (true WORM).
+**Recommendation:** Use **File adapter** for lowest latency, **PostgreSQL** for queryability. For cloud WORM, use external archival (filter by `retention_until`).
 
 ---