omnibase_infra 0.2.6__py3-none-any.whl

omnibase_infra/validation/validation_exemptions.yaml

@@ -0,0 +1,2033 @@
+# Validation Exemption Patterns
+# ============================================================================
+# These patterns exempt specific code from validation rules.
+#
+# Why exemptions exist:
+# Infrastructure code often has legitimate architectural reasons to exceed
+# default thresholds (method counts, parameter counts, etc.). Rather than
+# raising global thresholds or suppressing warnings entirely, we document
+# specific exemptions with their rationale.
+#
+# How exemptions work:
+# - Uses regex-based matching to handle code evolution gracefully
+# - All specified pattern fields must match for exemption to apply
+# - Unspecified optional fields are not checked (match everything)
+# - Uses re.search() for flexible substring matching
+#
+# Pattern fields:
+# - file_pattern: Regex matching the filename (required in practice)
+# - class_pattern: Optional regex for class name context
+# - method_pattern: Optional regex for method name context
+# - violation_pattern: Regex matching the violation type
+#
+# Adding new exemptions:
+# 1. Identify the exact violation message from validator output
+# 2. Create minimal patterns to match only that specific case
+# 3. Document the rationale and link to relevant tickets
+# 4. Run tests to verify the exemption works
+# ============================================================================
+# Schema version for future compatibility
+schema_version: "1.0.0"
+# ==============================================================================
+# Skip Directories Configuration
+# ==============================================================================
+# Directories to exclude from validation scans. Uses EXACT name matching
+# (case-sensitive) to prevent false positives from substring matching.
+#
+# Matching behavior:
+# - Only parent directories are checked (filenames are NOT checked)
+# - Matching is case-sensitive (Linux standard)
+# - Uses set membership for O(1) lookup performance
+# - A path is skipped if ANY parent directory matches exactly
+#
+# Examples of what IS skipped:
+# - /src/archive/foo.py (has "archive" directory)
+# - /src/__pycache__/bar.pyc (has "__pycache__" directory)
+# - /src/.venv/lib/baz.py (has ".venv" directory)
+#
+# Examples of what is NOT skipped (no false positives):
+# - /src/archived_feature/foo.py ("archived_feature" != "archived")
+# - /src/my_archive/bar.py ("my_archive" != "archive")
+# - /src/Archive/baz.py (case-sensitive: "Archive" != "archive")
+# - /src/archive.py (filename not checked, only directories)
+#
+# To add new skip directories:
+# 1. Add to the appropriate category below
+# 2. Document why this directory should be skipped
+# 3. Run tests to verify (tests/unit/validation/test_path_skipping.py)
+# ==============================================================================
+skip_directories:
+  # Historical/demo code - not subject to current validation rules
+  historical:
+    - archive # Historical code preserved for reference
+    - archived # Alternative naming for archived code
+    - examples # Demo code that may intentionally show anti-patterns
+  # Python bytecode and caches - generated files, not source code
+  caches:
+    - __pycache__ # Python bytecode cache
+    - .mypy_cache # mypy type checking cache
+    - .pytest_cache # pytest cache directory
+  # Virtual environments - third-party code, not project code
+  virtual_environments:
+    - .venv # Standard virtual environment directory
+    - venv # Alternative virtual environment directory
+  # Build outputs - generated during build, not source code
+  build_outputs:
+    - build # Python build output directory
+    - dist # Distribution packages output
+    - .eggs # setuptools eggs directory
+  # Version control - repository metadata, not project code
+  version_control:
+    - .git # Git repository metadata
+  # Testing infrastructure - testing tool directories
+  testing:
+    - .tox # Tox testing directory
+  # Node.js - JavaScript/Node dependencies (if any JS in repo)
+  nodejs:
+    - node_modules # Node.js package dependencies
+# Pattern validator exemptions
+# These handle method count, parameter count, naming, and style violations
+pattern_exemptions:
+  # ==========================================================================
+  # ModelRuntimeContractConfig Exemptions (OMN-1519)
+  # ==========================================================================
+  # Data model with cohesive accessor properties for querying loaded contracts.
+  # All methods serve same purpose: querying contract_results collection.
+  # Properties: all_successful, success_rate, successful_results, failed_results,
+  #             handler_routing_configs, operation_bindings_configs, error_messages
+  # Methods: get_routing_for_contract, get_bindings_for_contract, __bool__, __str__
+  - file_pattern: 'model_runtime_contract_config\.py'
+    class_pattern: "Class 'ModelRuntimeContractConfig'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Cohesive data model with accessor properties that all query the same contract_results collection. Properties provide convenient typed access to loaded configs, success metrics, and error details. Breaking into smaller classes would reduce cohesion without meaningful benefit.
+
+    documentation:
+      - OMN-1519 PR description
+    ticket: OMN-1519
+  # ==========================================================================
+  # EventBusKafka Exemptions (OMN-934, OMN-1305)
+  # ==========================================================================
+  # Event bus pattern requires many methods for lifecycle (start/stop/health),
+  # pub/sub (subscribe/unsubscribe/publish), circuit breaker, protocol compatibility.
+  # Complexity managed through mixin composition (MixinKafkaDlq, MixinKafkaBroadcast).
+  # See: event_bus_kafka.py class docstring, CLAUDE.md "Accepted Pattern Exceptions"
+  - file_pattern: 'event_bus_kafka\.py'
+    class_pattern: "Class 'EventBusKafka'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Event bus pattern requires lifecycle (start/stop/health), pub/sub (subscribe/unsubscribe/publish), circuit breaker, and protocol compatibility methods. DLQ and broadcast methods extracted to mixins. Core class has 12+ methods for protocol compliance.
+
+    documentation:
+      - CLAUDE.md (Accepted Pattern Exceptions - EventBusKafka Complexity)
+      - docs/patterns/circuit_breaker_implementation.md
+    ticket: OMN-1305
+  - file_pattern: 'event_bus_kafka\.py'
+    method_pattern: "Function '__init__'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Configuration managed via ModelKafkaEventBusConfig. Init requires config model parameter.
+
+    documentation:
+      - CLAUDE.md (Accepted Pattern Exceptions - EventBusKafka Complexity)
+    ticket: OMN-1305
+  # ==========================================================================
+  # Protocol Plugin Architecture Exemptions
+  # ==========================================================================
+  # The 'execute' method name is a standard plugin architecture pattern.
+  # It's intentionally generic as it's the protocol-defined entry point.
+  # Design Doc: CLAUDE.md "ONEX Architecture" section - Protocol-based plugin execution pattern
+  - file_pattern: 'protocol_plugin_compute\.py'
+    violation_pattern: "Function name 'execute' is too generic"
+    reason: Standard plugin architecture pattern - execute is the protocol-defined entry point.
+    documentation:
+      - CLAUDE.md (ONEX Architecture - Protocol Resolution section)
+    ticket: null
+  - file_pattern: 'plugin_compute_base\.py'
+    violation_pattern: "Function name 'execute' is too generic"
+    reason: Base class implements protocol pattern - execute is the standard entry point.
+    documentation:
+      - CLAUDE.md (ONEX Architecture - Protocol Resolution section)
+    ticket: null
+  # ==========================================================================
+  # RuntimeHostProcess Exemptions (OMN-756)
+  # ==========================================================================
+  # Central coordinator class that legitimately requires multiple methods for:
+  # - Lifecycle management (start, stop, health_check)
+  # - Message handling (_on_message, _handle_envelope)
+  # - Graceful shutdown (shutdown_ready, drain logic)
+  # - Handler management (register_handler, get_handler)
+  - file_pattern: 'service_runtime_host_process\.py'
+    class_pattern: "Class 'RuntimeHostProcess'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Central coordinator pattern requires lifecycle management, message handling, graceful shutdown, and handler management methods.
+
+    documentation:
+      - docs/architecture/RUNTIME_HOST_IMPLEMENTATION_PLAN.md
+      - docs/adr/ADR-001-graceful-shutdown-drain-period.md
+    ticket: OMN-756
+  - file_pattern: 'service_runtime_host_process\.py'
+    method_pattern: "Function '__init__'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Central coordinator requires multiple configuration parameters: event_bus, input_topic, output_topic, config, handler_registry.
+
+    documentation:
+      - docs/architecture/RUNTIME_HOST_IMPLEMENTATION_PLAN.md
+    ticket: OMN-756
+  # ==========================================================================
+  # PolicyRegistry Exemptions
+  # ==========================================================================
+  # Domain registry pattern requires comprehensive policy management operations.
+  # Design Doc: docs/patterns/container_dependency_injection.md - Registry patterns
+  - file_pattern: 'policy_registry\.py'
+    class_pattern: "Class 'PolicyRegistry'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Central registry pattern requires CRUD operations (register, get, update, remove), query operations (list, filter, search), and lifecycle operations (enable, disable, validate).
+
+    documentation:
+      - docs/patterns/container_dependency_injection.md (Registry patterns)
+      - CLAUDE.md (Container-Based Dependency Injection section)
+    ticket: null
+  - file_pattern: 'registry_policy\.py'
+    method_pattern: "Function 'register_policy'"
+    violation_pattern: 'has \d+ parameters'
+    reason: Policy registration requires multiple fields for complete policy definition. ModelPolicyRegistration is available as the preferred API for new code.
+    documentation:
+      - docs/patterns/container_dependency_injection.md
+    ticket: null
+  - file_pattern: 'registry_policy\.py'
+    class_pattern: "Class 'RegistryPolicy'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Registry pattern after mixin extraction (MixinPolicyValidation, MixinSemverCache). Core class has 12 methods for CRUD, query, and lifecycle operations. This is at the threshold and acceptable per CLAUDE.md registry patterns.
+
+    documentation:
+      - docs/patterns/container_dependency_injection.md
+    ticket: OMN-1305
+  # ==========================================================================
+  # Policy ID Exemptions (OMN-812)
+  # ==========================================================================
+  # policy_id is intentionally a human-readable string identifier (e.g., 'exponential_backoff'),
+  # NOT a UUID. The _id suffix triggers false positive UUID suggestions.
+  - file_pattern: 'model_policy_key\.py'
+    violation_pattern: "Field 'policy_id' should use UUID"
+    reason: >
+      policy_id is a human-readable string identifier (e.g., 'exponential_backoff'), not a UUID. The _id suffix triggers false positive.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions - semantic identifiers vs UUIDs)
+      - docs/patterns/container_dependency_injection.md (Registry patterns)
+    ticket: OMN-812
+  - file_pattern: 'model_policy_registration\.py'
+    violation_pattern: "Field 'policy_id' should use UUID"
+    reason: Same as ModelPolicyKey - semantic identifier, not UUID.
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions)
+    ticket: OMN-812
+  # ==========================================================================
+  # Infrastructure Handler Exemptions (OMN-1092)
+  # ==========================================================================
+  # Infrastructure handlers require multiple methods for: connection lifecycle,
+  # operation dispatching, health checks, and protocol-specific operations.
+  - file_pattern: 'handler_consul\.py'
+    class_pattern: "Class 'HandlerConsul'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Infrastructure handler pattern requires multiple methods: connection lifecycle (connect, disconnect), operation dispatch (handle_operation, handle_kv_*, handle_service_*), properties (handler_type, handler_category), and health/describe methods. This is standard for infrastructure handlers.
+
+    documentation:
+      - docs/architecture/HANDLER_PROTOCOL_DRIVEN_ARCHITECTURE.md
+      - CLAUDE.md (Infrastructure Patterns - Adapter Pattern)
+    ticket: OMN-1092
+  # ==========================================================================
+  # Projector Schema Model Exemptions (OMN-1168)
+  # ==========================================================================
+  # ModelProjectorSchema requires multiple methods for SQL generation, validation,
+  # and schema introspection operations.
+  - file_pattern: 'model_projector_schema\.py'
+    class_pattern: "Class 'ModelProjectorSchema'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Schema model requires SQL generation methods (to_create_table_sql, to_full_migration_sql), schema introspection (get_column_names, get_primary_key_columns), validation methods, and identifier quoting for complete projector schema management.
+
+    documentation:
+      - src/omnibase_infra/models/projectors/model_projector_schema.py (class docstring)
+    ticket: OMN-1168
+  # ==========================================================================
+  # Execution Shape Validator Exemptions (OMN-958)
+  # ==========================================================================
+  - file_pattern: 'enum_handler_type\.py'
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      EnumHandlerType defines ONEX handler architectural roles (InfraHandler, NodeHandler, etc.) which are architectural concepts, not implementation classes.
+
+    documentation:
+      - docs/architecture/HANDLER_PROTOCOL_DRIVEN_ARCHITECTURE.md
+      - CLAUDE.md (ONEX Architecture - Handler Types)
+    ticket: OMN-1092
+  - file_pattern: 'enum_handler_type_category\.py'
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      EnumHandlerTypeCategory defines ONEX handler behavioral classification (Compute, Effect, NondeterministicCompute) which are architectural concepts for policy envelopes, not implementation classes.
+
+    documentation:
+      - docs/architecture/HANDLER_PROTOCOL_DRIVEN_ARCHITECTURE.md
+      - CLAUDE.md (ONEX Architecture - Handler Classification)
+    ticket: OMN-1092
+  - file_pattern: 'validator_execution_shape\.py'
+    class_pattern: "Class name 'ModelDetectedNodeInfo'"
+    violation_pattern: "contains anti-pattern 'Model'"
+    reason: >
+      ModelDetectedNodeInfo is a validation data class for describing detected node information during AST analysis - follows Model* naming convention.
+
+    documentation:
+      - docs/validation/validator_reference.md
+    ticket: OMN-958
+  - file_pattern: 'validator_execution_shape\.py'
+    class_pattern: "Class 'ExecutionShapeValidator'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Validator class requires multiple methods for comprehensive AST analysis: validate_file, validate_directory, _extract_handlers, _find_handler_type, _detect_return_type, _analyze_return_statement, _check_forbidden_calls, _categorize_output. Cohesive validator pattern.
+
+    documentation:
+      - docs/as_is/02_NODE_EXECUTION_SHAPES.md
+      - docs/validation/validator_reference.md
+    ticket: OMN-958
+  # ==========================================================================
+  # Any Type Validator Exemptions (OMN-1276)
+  # ==========================================================================
+  # AST-based validator for Any type usage enforcement. The class requires
+  # multiple visitor methods and helper methods for comprehensive detection.
+  - file_pattern: 'validator_any_type\.py'
+    class_pattern: "Class 'AnyTypeDetector'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      AST visitor class after mixin extraction (MixinAnyTypeClassification, MixinAnyTypeExemption, MixinAnyTypeReporting). Core class has 12 methods for visit methods and annotation checking. This is at the threshold and acceptable per standard AST visitor pattern.
+
+    documentation:
+      - docs/decisions/adr-any-type-pydantic-workaround.md
+      - CLAUDE.md (Any Type CI Enforcement)
+    ticket: OMN-1276
+  - file_pattern: 'model_any_type_violation\.py'
+    violation_pattern: "Field 'context_name' might reference an entity"
+    reason: >
+      context_name is descriptive metadata (e.g., "process_event(payload)") showing where the violation occurred, not an entity reference requiring ID + display_name. It provides human-readable context for error messages.
+
+    documentation:
+      - docs/decisions/adr-any-type-pydantic-workaround.md
+    ticket: OMN-1276
+  # ==========================================================================
+  # RuntimeShapeValidator Exemptions
+  # ==========================================================================
+  # Design Doc: docs/patterns/error_handling_patterns.md - Validation error patterns
+  - file_pattern: 'validator_runtime_shape\.py'
+    method_pattern: "Function 'validate_handler_output'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Validation requires multiple context parameters for proper violation reporting: handler_type, output, output_category, source_file, line_number, correlation_id. These are distinct required contexts, not candidates for a model wrapper.
+
+    documentation:
+      - docs/patterns/error_handling_patterns.md (Validation error hierarchy)
+      - CLAUDE.md (ONEX Architecture - Contract-Driven section)
+    ticket: null
+  - file_pattern: 'validator_runtime_shape\.py'
+    method_pattern: "Function 'validate_and_raise'"
+    violation_pattern: 'has \d+ parameters'
+    reason: Same rationale as validate_handler_output - requires distinct context params.
+    documentation:
+      - docs/patterns/error_handling_patterns.md
+    ticket: null
+  # ==========================================================================
+  # MixinNodeIntrospection Exemptions (OMN-958)
+  # ==========================================================================
+  - file_pattern: 'mixin_node_introspection\.py'
+    method_pattern: "Function 'initialize_introspection'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Flexible initialization interface. The preferred method initialize_introspection_from_config() takes ModelIntrospectionConfig with parameter count of 2. Direct parameters method provides fine-grained control when needed.
+
+    documentation:
+      - CLAUDE.md (Node Introspection Security Considerations)
+    ticket: OMN-958
+  - file_pattern: 'mixin_node_introspection\.py'
+    class_pattern: "Class 'MixinNodeIntrospection'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Introspection mixin legitimately requires multiple methods: lifecycle (initialize_introspection, start/stop tasks), capability discovery (get_capabilities, get_endpoints, get_current_state), caching (invalidate_introspection_cache), publishing (publish_introspection), and background tasks (heartbeat, registry listener).
+
+    documentation:
+      - CLAUDE.md (Node Introspection Security Considerations)
+      - docs/architecture/REGISTRATION_ORCHESTRATOR_ARCHITECTURE.md
+    ticket: OMN-958
+  # ==========================================================================
+  # Message Dispatch Engine Exemptions (OMN-934, OMN-983)
+  # ==========================================================================
+  # Central dispatch coordinator pattern requires comprehensive routing capabilities.
+  - file_pattern: 'service_message_dispatch_engine\.py'
+    class_pattern: "Class 'MessageDispatchEngine'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Central dispatch coordinator requires: registration (register_dispatcher, register_route), routing (dispatch, get_dispatchers_for_message), metrics (get_dispatcher_metrics, get_dispatch_metrics), lifecycle (start, stop, health_check). This is a central coordinator pattern.
+
+    documentation:
+      - docs/architecture/MESSAGE_DISPATCH_ENGINE.md
+      - docs/as_is/05_RUNTIME_DISPATCH_SHAPES.md
+    ticket: OMN-934
+  - file_pattern: 'service_message_dispatch_engine\.py'
+    method_pattern: "Function '_build_log_context'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Log context builder intentionally takes many optional parameters to build structured log context. Each parameter is a distinct log field.
+
+    documentation:
+      - docs/architecture/MESSAGE_DISPATCH_ENGINE.md
+    ticket: OMN-934
+  - file_pattern: 'service_message_dispatch_engine\.py'
+    method_pattern: "Function '__init__'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Central dispatch coordinator requires multiple configuration parameters: context_enforcer, topic_parser, default_node_kind, logger, topic_to_dispatcher_map, category_dispatchers. These are distinct required contexts for dispatch orchestration.
+
+    documentation:
+      - docs/architecture/MESSAGE_DISPATCH_ENGINE.md
+    ticket: OMN-990
+  - file_pattern: 'service_message_dispatch_engine\.py'
+    method_pattern: "Function 'register_dispatcher'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Dispatcher registration requires multiple parameters for complete routing configuration: dispatcher, category, node_kind, topic_patterns, priority. These are distinct routing configuration fields.
+
+    documentation:
+      - docs/architecture/MESSAGE_DISPATCH_ENGINE.md
+    ticket: OMN-990
+  # ==========================================================================
+  # RegistryDispatcher Exemptions (OMN-934)
+  # ==========================================================================
+  - file_pattern: 'registry_dispatcher\.py'
+    class_pattern: "Class 'RegistryDispatcher'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Domain registry pattern requires CRUD + query operations: registration (register, unregister), lookup (get_by_id, get_by_type, get_all), metrics (get_metrics). This is an established domain registry pattern.
+
+    documentation:
+      - docs/architecture/MESSAGE_DISPATCH_ENGINE.md
+      - docs/patterns/container_dependency_injection.md (Registry patterns)
+    ticket: OMN-934
+  # ==========================================================================
+  # Dispatch Model Semantic Identifier Exemptions (OMN-983)
+  # ==========================================================================
+  # dispatcher_id, route_id are semantic identifiers (like policy_id), NOT UUIDs.
+  # They are human-readable strings that identify dispatchers/routes by name.
+  - file_pattern: 'model_dispatcher_registration\.py'
+    violation_pattern: "Field 'dispatcher_id' should use UUID"
+    reason: >
+      dispatcher_id is a human-readable semantic identifier (e.g., "kafka-main-dispatcher"), not a UUID. Similar to policy_id pattern.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions)
+      - docs/architecture/MESSAGE_DISPATCH_ENGINE.md
+    ticket: OMN-983
+  - file_pattern: 'model_dispatcher_registration\.py'
+    violation_pattern: 'dispatcher_name.*entity'
+    reason: >
+      dispatcher_name is a display name for the dispatcher, paired with dispatcher_id as the semantic identifier. This follows the ID + display_name pattern.
+
+    documentation:
+      - docs/architecture/MESSAGE_DISPATCH_ENGINE.md
+    ticket: OMN-983
+  - file_pattern: 'model_dispatcher_metrics\.py'
+    violation_pattern: "Field 'dispatcher_id' should use UUID"
+    reason: >
+      dispatcher_id is a human-readable semantic identifier, not a UUID. Consistent with model_dispatcher_registration.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions)
+    ticket: OMN-983
+  - file_pattern: 'model_dispatch_route\.py'
+    violation_pattern: "Field 'route_id' should use UUID"
+    reason: >
+      route_id is a human-readable semantic identifier (e.g., "default-route"), not a UUID.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions)
+      - docs/architecture/MESSAGE_DISPATCH_ENGINE.md
+    ticket: OMN-983
+  - file_pattern: 'model_dispatch_route\.py'
+    violation_pattern: "Field 'dispatcher_id' should use UUID"
+    reason: >
+      dispatcher_id is a human-readable semantic identifier, consistent across dispatch models.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions)
+    ticket: OMN-983
+  - file_pattern: 'model_dispatch_metrics\.py'
+    method_pattern: "Function 'record_dispatch'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Metrics recording requires multiple parameters for complete dispatch tracking: identifiers (dispatcher_id, route_id, topic, message_type), timing (start_time, end_time, duration_ms), status (success, error_code, error_message).
+
+    documentation:
+      - docs/architecture/MESSAGE_DISPATCH_ENGINE.md
+    ticket: OMN-983
+  # ==========================================================================
+  # RuntimeScheduler Semantic Identifier Exemptions (OMN-953)
+  # ==========================================================================
+  # scheduler_id is a human-readable semantic identifier set via environment variable
+  # (e.g., "runtime-scheduler-prod-1"), NOT a UUID. Follows same pattern as policy_id
+  # and dispatcher_id.
+  - file_pattern: 'model_runtime_scheduler_config\.py'
+    violation_pattern: "Field 'scheduler_id' should use UUID"
+    reason: >
+      scheduler_id is a human-readable semantic identifier (e.g., "runtime-scheduler-prod-1") set via RUNTIME_SCHEDULER_ID environment variable. Not a UUID - follows policy_id/dispatcher_id pattern.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions)
+    ticket: OMN-953
+  - file_pattern: 'model_runtime_scheduler_metrics\.py'
+    violation_pattern: "Field 'scheduler_id' should use UUID"
+    reason: >
+      scheduler_id is a human-readable semantic identifier, consistent with model_runtime_scheduler_config.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions)
+    ticket: OMN-953
+  - file_pattern: 'model_runtime_tick\.py'
+    violation_pattern: "Field 'scheduler_id' should use UUID"
+    reason: >
+      scheduler_id identifies which runtime scheduler instance emitted the tick. Human-readable identifier, consistent across scheduler models.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions)
+    ticket: OMN-953
+  # ==========================================================================
+  # TransitionNotificationPublisher publisher_id Exemption (OMN-1139)
+  # ==========================================================================
+  # publisher_id is a human-readable semantic identifier similar to scheduler_id.
+  # It identifies the publisher instance and may be auto-generated or user-specified.
+  - file_pattern: 'model_transition_notification_publisher_metrics\.py'
+    violation_pattern: "Field 'publisher_id' should use UUID"
+    reason: >
+      publisher_id is a human-readable semantic identifier (e.g., "transition-publisher-<uuid>") that identifies the publisher instance. Follows the same pattern as scheduler_id.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions)
+    ticket: OMN-1139
+  # ==========================================================================
+  # ModelTransitionNotificationOutboxMetrics table_name Exemption (OMN-1139)
+  # ==========================================================================
+  # table_name is the database table name string, not an entity reference.
+  - file_pattern: 'model_transition_notification_outbox_metrics\.py'
+    violation_pattern: "Field 'table_name' might reference an entity"
+    reason: >
+      table_name is the database table name string (e.g., "transition_notification_outbox"), not an entity reference. It identifies the outbox table for metrics reporting and does not require ID + display_name pattern.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions)
+    ticket: OMN-1139
+  # ==========================================================================
+  # TransitionNotificationOutbox Method Count Exemption (OMN-1139)
+  # ==========================================================================
+  # Outbox pattern requires lifecycle (start/stop), storage (store/cleanup),
+  # processing (process_pending), and multiple config properties for observability.
+  # NOTE: Pattern anchored with src/omnibase_infra/runtime/ prefix to match only
+  # the production file, not test files.
+  - file_pattern: 'src/omnibase_infra/runtime/transition_notification_outbox\.py'
+    class_pattern: "Class 'TransitionNotificationOutbox'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Transactional outbox pattern inherently requires: lifecycle methods (start/stop), storage operations (store/cleanup_processed), processing (process_pending), background loop (_processor_loop), metrics (get_metrics), and configuration properties (table_name, batch_size, poll_interval, is_running, shutdown_timeout, notifications_stored/processed/failed, strict_transaction_mode). Method count is driven by pattern requirements, not poor design.
+
+    documentation:
+      - src/omnibase_infra/schemas/schema_transition_notification_outbox.sql
+    ticket: OMN-1139
+  # ==========================================================================
+  # ServiceTimeoutEmitter/Scanner Naming Exemptions (OMN-1055)
+  # ==========================================================================
+  # These service classes follow the CLAUDE.md Service<Name> naming convention.
+  # Service files use service_<name>.py with Service<Name> class names.
+  - file_pattern: 'service_timeout_emitter\.py'
+    class_pattern: "Class name 'ServiceTimeoutEmitter'"
+    violation_pattern: "contains anti-pattern 'Service'"
+    reason: >
+      Follows CLAUDE.md Service<Name> naming convention for service classes. Service files use service_<name>.py with Service<Name> class names.
+
+    documentation:
+      - CLAUDE.md (File & Class Naming - Service convention)
+    ticket: OMN-1055
+  - file_pattern: 'service_timeout_scanner\.py'
+    class_pattern: "Class name 'ServiceTimeoutScanner'"
+    violation_pattern: "contains anti-pattern 'Service'"
+    reason: >
+      Follows CLAUDE.md Service<Name> naming convention for service classes. Service files use service_<name>.py with Service<Name> class names.
+
+    documentation:
+      - CLAUDE.md (File & Class Naming - Service convention)
+    ticket: OMN-1055
+  # ==========================================================================
+  # ServiceHealth Exemptions (OMN-529)
+  # ==========================================================================
+  # ServiceHealth follows the CLAUDE.md Service<Name> naming convention and
+  # requires multiple __init__ parameters to support dual initialization modes
+  # (direct runtime injection and container-based DI).
+  - file_pattern: 'service_health\.py'
+    class_pattern: "Class name 'ServiceHealth'"
+    violation_pattern: "contains anti-pattern 'Service'"
+    reason: >
+      Follows CLAUDE.md Service<Name> naming convention for service classes. Service files use service_<name>.py with Service<Name> class names.
+
+    documentation:
+      - CLAUDE.md (File & Class Naming - Service convention)
+    ticket: OMN-529
+  - file_pattern: 'service_dlq_tracking\.py'
+    class_pattern: "Class name 'ServiceDlqTracking'"
+    violation_pattern: "contains anti-pattern 'Service'"
+    reason: >
+      Follows CLAUDE.md Service<Name> naming convention for service classes. Service files use service_<name>.py with Service<Name> class names.
+
+    documentation:
+      - CLAUDE.md (File & Class Naming - Service convention)
+    ticket: OMN-1270
+  - file_pattern: 'service_capability_query\.py'
+    class_pattern: "Class name 'ServiceCapabilityQuery'"
+    violation_pattern: "contains anti-pattern 'Service'"
+    reason: >
+      Follows CLAUDE.md Service<Name> naming convention for service classes. Service files use service_<name>.py with Service<Name> class names.
+
+    documentation:
+      - CLAUDE.md (File & Class Naming - Service convention)
+    ticket: OMN-1135
+  - file_pattern: 'service_node_selector\.py'
+    class_pattern: "Class name 'ServiceNodeSelector'"
+    violation_pattern: "contains anti-pattern 'Service'"
+    reason: >
+      Follows CLAUDE.md Service<Name> naming convention for service classes. Service files use service_<name>.py with Service<Name> class names.
+
+    documentation:
+      - CLAUDE.md (File & Class Naming - Service convention)
+    ticket: OMN-1135
+  - file_pattern: 'service_snapshot\.py'
+    class_pattern: "Class name 'ServiceSnapshot'"
+    violation_pattern: "contains anti-pattern 'Service'"
+    reason: >
+      Follows CLAUDE.md Service<Name> naming convention for service classes. ServiceSnapshot provides generic snapshot infrastructure for state persistence. File renamed from snapshot_repository.py per PR review feedback.
+
+    documentation:
+      - CLAUDE.md (File & Class Naming - Service convention)
+    ticket: OMN-1246
+  - file_pattern: 'service_health\.py'
+    method_pattern: "Function '__init__'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      ServiceHealth supports dual initialization modes (direct runtime injection and container-based DI) requiring multiple optional parameters. This is intentional to support migration from legacy patterns to ONEX-compliant container injection.
+
+    documentation:
+      - CLAUDE.md (Container-Based Dependency Injection)
+    ticket: OMN-529
+  # ==========================================================================
+  # Consul Service ID Exemptions (OMN-889)
+  # ==========================================================================
+  # consul_service_id is a Consul-specific identifier that is a user-defined string,
+  # NOT a UUID. The Consul API accepts any string as a service ID. This field is
+  # named with the 'consul_' prefix to clarify it's a Consul concept.
+  - file_pattern: 'model_consul_register_payload\.py'
+    violation_pattern: "Field 'consul_service_id' should use UUID"
+    reason: >
+      consul_service_id is a Consul-specific identifier that is a user-defined string, not a UUID. The Consul API accepts any string as a service ID.
+
+    documentation:
+      - docs/architecture/REGISTRATION_ORCHESTRATOR_ARCHITECTURE.md
+      - HashiCorp Consul Service Discovery API (https://developer.hashicorp.com/consul/api-docs/agent/service)
+    ticket: OMN-889
+  - file_pattern: 'model_consul_deregister_payload\.py'
+    violation_pattern: "Field 'consul_service_id' should use UUID"
+    reason: >
+      consul_service_id is a Consul-specific identifier that is a user-defined string, not a UUID. The Consul API accepts any string as a service ID.
+
+    documentation:
+      - docs/architecture/REGISTRATION_ORCHESTRATOR_ARCHITECTURE.md
+    ticket: OMN-889
+  # ==========================================================================
+  # MessageTypeRegistry Exemptions (OMN-983)
+  # ==========================================================================
+  - file_pattern: 'registry_message_type\.py'
+    class_pattern: "Class 'RegistryMessageType'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Domain registry pattern after mixin extraction (MixinMessageTypeRegistration, MixinMessageTypeQuery). Core class has 11 methods for domain registry operations. This is below the threshold and acceptable per established domain registry pattern.
+
+    documentation:
+      - docs/architecture/MESSAGE_DISPATCH_ENGINE.md
+      - docs/patterns/container_dependency_injection.md (Registry patterns)
+    ticket: OMN-983
+  # ==========================================================================
+  # Idempotency Store Configuration Exemptions (OMN-945)
+  # ==========================================================================
+  # table_name is a database configuration field specifying the PostgreSQL table
+  # name for storing idempotency records. It is NOT an entity reference.
+  - file_pattern: 'model_postgres_idempotency_store_config\.py'
+    violation_pattern: "Field 'table_name' might reference an entity"
+    reason: >
+      table_name is a database configuration parameter specifying the PostgreSQL table name for storing idempotency records (default: "idempotency_records"). This is infrastructure configuration, not an entity reference.
+
+    documentation:
+      - docs/patterns/retry_backoff_compensation_strategy.md (Idempotency patterns)
+    ticket: OMN-945
+  # ==========================================================================
+  # RegistryCompute Exemptions (OMN-811)
+  # ==========================================================================
+  # Central registry pattern for compute plugins follows same patterns as
+  # PolicyRegistry, MessageTypeRegistry, and RegistryDispatcher.
+  - file_pattern: 'registry_compute\.py'
+    class_pattern: "Class 'RegistryCompute'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Central registry pattern requires comprehensive plugin management: CRUD operations (register, unregister, get), query operations (list_keys, list_plugins, get_all), version resolution (get_latest_version, _parse_version), validation (protocol compliance, async detection), and container integration. This is an established domain registry pattern consistent with PolicyRegistry, MessageTypeRegistry.
+
+    documentation:
+      - docs/patterns/container_dependency_injection.md (Registry patterns)
+      - CLAUDE.md (Registry Naming Conventions)
+    ticket: OMN-811
+  - file_pattern: 'registry_compute\.py'
+    method_pattern: "Function 'register_plugin'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Plugin registration requires multiple parameters for complete registration: plugin_id, plugin_class, version, description, deterministic_async. This is a convenience method; the model-based register() method is the preferred API.
+
+    documentation:
+      - docs/patterns/container_dependency_injection.md
+    ticket: OMN-811
+  # ==========================================================================
+  # ComputeRegistryError Exemptions (OMN-811)
+  # ==========================================================================
+  # Error classes require multiple context parameters for comprehensive error reporting.
+  - file_pattern: 'error_compute_registry\.py'
+    method_pattern: "Function '__init__'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Error class requires multiple contextual parameters for debugging: message, plugin_id, version, registered_plugins, context, and **extra_context. These are distinct error context fields needed for comprehensive error reporting.
+
+    documentation:
+      - docs/patterns/error_handling_patterns.md
+      - CLAUDE.md (Infrastructure Error Patterns)
+    ticket: OMN-811
+  # ==========================================================================
+  # EventBusRegistryError Exemptions (OMN-1276)
+  # ==========================================================================
+  # Error classes require multiple context parameters for comprehensive error reporting.
+  - file_pattern: 'error_event_bus_registry\.py'
+    method_pattern: "Function '__init__'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Error class requires multiple contextual parameters for debugging: message, bus_kind, bus_class, available_kinds, existing_class, context, and **extra_context. These are distinct error context fields needed for comprehensive error reporting.
+
+    documentation:
+      - docs/patterns/error_handling_patterns.md
+      - CLAUDE.md (Infrastructure Error Patterns)
+    ticket: OMN-1276
+  # ==========================================================================
+  # MessageTypeRegistryError Exemptions (OMN-983)
+  # ==========================================================================
+  # Error classes require multiple context parameters for comprehensive error reporting.
+  - file_pattern: 'error_message_type_registry\.py'
+    method_pattern: "Function '__init__'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Error class requires multiple contextual parameters for debugging: message, message_type, domain, category, context, and **extra_context. These are distinct error context fields needed for comprehensive error reporting.
+
+    documentation:
+      - docs/patterns/error_handling_patterns.md
+      - CLAUDE.md (Infrastructure Error Patterns)
+    ticket: OMN-983
+  # ==========================================================================
+  # Compute Plugin ID Exemptions (OMN-811)
+  # ==========================================================================
+  # plugin_id is a semantic identifier (e.g., 'json_normalizer'), NOT a UUID.
+  # Follows same pattern as policy_id, dispatcher_id, scheduler_id.
+  - file_pattern: 'model_compute_key\.py'
+    violation_pattern: "Field 'plugin_id' should use UUID"
+    reason: >
+      plugin_id is a human-readable semantic identifier (e.g., 'json_normalizer'), not a UUID. This follows the same pattern as policy_id, dispatcher_id, and scheduler_id.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions - semantic identifiers vs UUIDs)
+      - docs/patterns/container_dependency_injection.md
+    ticket: OMN-811
+  - file_pattern: 'model_compute_registration\.py'
+    violation_pattern: "Field 'plugin_id' should use UUID"
+    reason: >
+      plugin_id is a human-readable semantic identifier, consistent with ModelComputeKey. Follows the policy_id/dispatcher_id pattern.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions)
+    ticket: OMN-811
+  # ==========================================================================
+  # Consul Intent Payload Exemptions (OMN-888)
+  # ==========================================================================
+  # service_name in ModelConsulIntentPayload is the Consul service name to register,
+  # NOT a reference to an internal entity. It is a Consul-specific configuration field.
+  - file_pattern: 'model_consul_intent_payload\.py'
+    violation_pattern: "Field 'service_name' might reference an entity"
+    reason: >
+      service_name is the Consul service name to register in service discovery (e.g., "node-effect-123"). This is Consul-specific configuration, not an entity reference. The field specifies how the node appears in Consul's service catalog.
+
+    documentation:
+      - docs/architecture/REGISTRATION_ORCHESTRATOR_ARCHITECTURE.md
+      - HashiCorp Consul Service Discovery API (https://developer.hashicorp.com/consul/api-docs/agent/service)
+    ticket: OMN-888
+  # ==========================================================================
+  # Private Class Naming Exemptions (OMN-811)
+  # ==========================================================================
+  # Private helper classes (prefixed with _) follow PascalCase after the underscore.
+  # The pattern validator's regex expects names to start with uppercase, but private
+  # classes correctly use underscore prefix + PascalCase (e.g., _MetricsTimer).
+  - file_pattern: 'registry_compute\.py'
+    class_pattern: "Class name '_MetricsTimer'"
+    violation_pattern: "should use PascalCase"
+    reason: >
+      _MetricsTimer IS valid PascalCase for a private class. The underscore prefix indicates private visibility, and "MetricsTimer" follows PascalCase. The validator regex doesn't account for underscore-prefixed private classes.
+
+    documentation:
+      - PEP 8 - Naming Conventions (https://peps.python.org/pep-0008/#naming-conventions)
+      - CLAUDE.md (File & Class Naming Conventions)
+    ticket: OMN-811
+  # ==========================================================================
+  # Plugin Models Exemptions (OMN-811)
+  # ==========================================================================
+  # ModelPluginContext uses str for correlation_id for flexibility - plugins may
+  # receive correlation IDs from various sources as strings. This is intentional
+  # to support diverse plugin use cases without requiring UUID conversion.
+  - file_pattern: 'model_plugin_context\.py'
+    violation_pattern: "Field 'correlation_id' should use UUID"
+    reason: >
+      Plugin context accepts correlation_id as string for flexibility. Plugins may receive correlation IDs from various sources that are not UUIDs. String type allows compatibility with diverse plugin input sources.
+
+    documentation:
+      - docs/patterns/correlation_id_tracking.md
+    ticket: OMN-811
+  # ==========================================================================
+  # MCP Handler Model Exemptions (OMN-1288)
+  # ==========================================================================
+  # tool_name in ModelMcpToolCall is the MCP protocol identifier for the tool
+  # to invoke (e.g., "get_weather", "search_documents"). It is NOT an entity
+  # reference requiring UUID + display_name pattern - it's a protocol-level
+  # identifier defined by the MCP specification.
+  - file_pattern: 'model_mcp_tool_call\.py'
+    violation_pattern: "Field 'tool_name' might reference an entity"
+    reason: >
+      tool_name is an MCP protocol identifier for the tool to invoke (e.g., "get_weather"). This is a protocol-level identifier from the Model Context Protocol specification, not an entity reference.
+
+    documentation:
+      - Model Context Protocol Specification (https://modelcontextprotocol.io/)
+    ticket: OMN-1288
+  # ==========================================================================
+  # Corpus Capture Model Exemptions (OMN-1203)
+  # ==========================================================================
+  # corpus_display_name in ModelCaptureConfig is a user-provided label for the
+  # corpus (e.g., "regression-suite-v1"). It is NOT an entity reference - it's
+  # simply a human-readable display name for configuration.
+  - file_pattern: 'model_capture_config\.py'
+    violation_pattern: "Field 'corpus_display_name' might reference an entity"
+    reason: >
+      corpus_display_name is a user-provided display label for the corpus (e.g., "regression-suite-v1"). This is a configuration display name, not an entity reference requiring UUID + display_name pattern.
+
+    documentation:
+      - src/omnibase_infra/models/corpus/model_capture_config.py (class docstring)
+    ticket: OMN-1203
+  # ==========================================================================
+  # Union Reduction Phase 2 Model Exemptions (OMN-1002)
+  # ==========================================================================
+  # These models use builder patterns with many convenience methods.
+  # Method counts exceed thresholds but provide valuable developer ergonomics.
+  # ModelLogContext - Structured logging context with builder pattern
+  - file_pattern: 'model_log_context\.py'
+    class_pattern: "Class 'ModelLogContext'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Builder pattern model for structured logging with fluent interface. Many methods provide convenience factories (for_event_bus, for_dispatch, for_error) and builder methods (with_*). This is intentional API design for developer ergonomics.
+
+    documentation:
+      - docs/patterns/correlation_id_tracking.md
+      - CLAUDE.md (Type Annotation Conventions)
+    ticket: OMN-1002
+  - file_pattern: 'model_log_context\.py'
+    violation_pattern: "Field 'correlation_id' should use UUID"
+    reason: >
+      correlation_id is stored as str for logging compatibility. Log formatters expect string values. The correlation ID is typically stringified from UUID before logging anyway.
+
+    documentation:
+      - docs/patterns/correlation_id_tracking.md
+    ticket: OMN-1002
+  - file_pattern: 'model_log_context\.py'
+    violation_pattern: "Field 'group_id' should use UUID"
+    reason: >
+      group_id is Kafka consumer group ID which is a string, not a UUID. This is infrastructure-specific and follows Kafka naming conventions.
+
+    documentation:
+      - Apache Kafka Consumer Group Configuration (https://kafka.apache.org/documentation/#consumerconfigs_group.id)
+    ticket: OMN-1002
+  - file_pattern: 'model_log_context\.py'
+    violation_pattern: "Field 'service_name' might reference an entity"
+    reason: >
+      service_name is a logging field for identifying the service (e.g., "kafka", "consul"). It is NOT an entity reference but a simple label for log correlation.
+
+    documentation:
+      - docs/patterns/correlation_id_tracking.md
+    ticket: OMN-1002
+  # ModelDispatchLogContext - Dispatch-specific logging
+  - file_pattern: 'model_dispatch_log_context\.py'
+    class_pattern: "Class 'ModelDispatchLogContext'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Builder pattern model for dispatch logging with factory methods for common patterns (for_dispatch_start, for_dispatch_complete, for_dispatch_error). Intentional API design.
+
+    documentation:
+      - docs/architecture/MESSAGE_DISPATCH_ENGINE.md
+      - docs/patterns/correlation_id_tracking.md
+    ticket: OMN-1002
+  - file_pattern: 'model_dispatch_log_context\.py'
+    violation_pattern: "Field 'dispatcher_id' should use UUID"
+    reason: >
+      dispatcher_id is a user-defined string identifier for dispatchers, not a UUID. Dispatchers are registered with string IDs for readability in logs and configuration.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions)
+    ticket: OMN-1002
+  - file_pattern: 'model_dispatch_log_context\.py'
+    method_pattern: "Function 'for_dispatch_complete'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Factory method that captures all dispatch completion context. Parameters are optional with defaults. Breaking into multiple calls would reduce usability.
+
+    documentation:
+      - docs/architecture/MESSAGE_DISPATCH_ENGINE.md
+    ticket: OMN-1002
+  - file_pattern: 'model_dispatch_log_context\.py'
+    method_pattern: "Function 'for_dispatch_error'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Factory method that captures all dispatch error context. Parameters are optional with defaults. Breaking into multiple calls would reduce usability.
+
+    documentation:
+      - docs/architecture/MESSAGE_DISPATCH_ENGINE.md
+    ticket: OMN-1002
+  # ModelDispatchOutcome - Dispatcher output normalization
+  - file_pattern: 'model_dispatch_outcome\.py'
+    class_pattern: "Class 'ModelDispatchOutcome'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Model with multiple factory methods (none, single, multiple, from_legacy_output) and convenience properties (is_empty, has_topics, single_topic, has_single_topic). Provides comprehensive API for handling dispatcher outputs.
+
+    documentation:
+      - docs/architecture/MESSAGE_DISPATCH_ENGINE.md
+      - docs/design/ADR_DISPATCHER_TYPE_SAFETY.md
+    ticket: OMN-1002
+  # ==========================================================================
+  # Failed Component Model Exemptions (OMN-1007)
+  # ==========================================================================
+  # component_name in ModelFailedComponent is a simple string identifier for
+  # the component that failed during shutdown (e.g., "KafkaEventBus", "VaultAdapter").
+  # It is NOT an entity reference requiring UUID + display_name pattern.
+  - file_pattern: 'model_failed_component\.py'
+    violation_pattern: "Field 'component_name' might reference an entity"
+    reason: >
+      component_name is a simple string identifier for the failed component (e.g., "KafkaEventBus"). This is a shutdown tracking field, not an entity reference. The component is identified by its type name, not by a UUID.
+
+    documentation:
+      - docs/adr/ADR-001-graceful-shutdown-drain-period.md
+      - CLAUDE.md (Model Field Naming - computed display names)
+    ticket: OMN-1007
+  # ==========================================================================
+  # ModelRegistryResponse Factory Method Exemptions (PR #79)
+  # ==========================================================================
+  # from_backend_results is a classmethod factory that requires all parameters
+  # to construct a response from individual backend results. Each parameter is
+  # a distinct required context for computing the response status.
+  - file_pattern: 'model_registry_response\.py'
+    method_pattern: "Function 'from_backend_results'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Classmethod factory requires all parameters to construct response from backend results: node_id, correlation_id, consul_result, postgres_result, timestamp. These are distinct required inputs for computing status, processing_time, and error_summary.
+
+    documentation:
+      - docs/architecture/REGISTRATION_ORCHESTRATOR_ARCHITECTURE.md
+      - CLAUDE.md (Factory Method Patterns)
+    ticket: PR-79
+  # ==========================================================================
+  # Union Reduction Phase 3 Result Model Exemptions (OMN-1003)
+  # ==========================================================================
+  # Result models use comprehensive APIs with factory methods, computed properties,
+  # and convenience methods for developer ergonomics.
+  - file_pattern: 'model_execution_shape_validation_result\.py'
+    class_pattern: "Class 'ModelExecutionShapeValidationResult'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Result model with comprehensive API: computed properties (has_blocking, violation_count, blocking_count, warning_count), factory methods (from_violations, success, from_legacy_result), utility methods (to_legacy_result, format_for_ci), and dunder methods (__bool__, __str__). This is intentional API design for CI integration and developer ergonomics.
+
+    documentation:
+      - docs/validation/validator_reference.md
+      - CLAUDE.md (Custom __bool__ for Result Models)
+    ticket: OMN-1003
+  # ==========================================================================
+  # OMN-1004: Union Reduction Phase 4 - New Model Exemptions
+  # ==========================================================================
+  # ModelCircuitBreakerConfig - service_name is a service identifier string
+  - file_pattern: 'model_circuit_breaker_config\.py'
+    violation_pattern: "Field 'service_name' might reference an entity"
+    reason: >
+      service_name is a string identifier for circuit breaker monitoring (e.g., "kafka.producer", "consul.client"). It is NOT an entity reference but a simple label for observability and logging purposes.
+
+    documentation:
+      - CLAUDE.md (Circuit Breaker Pattern section)
+    ticket: OMN-1004
+  # ModelOperationContext - operation_name is an operation identifier string
+  - file_pattern: 'model_operation_context\.py'
+    violation_pattern: "Field 'operation_name' might reference an entity"
+    reason: >
+      operation_name is a string identifier for handler operations (e.g., "connect", "publish", "query"). It is NOT an entity reference but a simple label for operation tracking and timeout context.
+
+    documentation:
+      - CLAUDE.md (Handler Refactoring section)
+    ticket: OMN-1004
+  # ModelValidationResult - field_name is the name of a validated field
+  - file_pattern: 'registration_reducer\.py'
+    violation_pattern: "Field 'field_name' might reference an entity"
+    reason: >
+      field_name is a string containing the name of a field being validated (e.g., "node_id", "name"). It is NOT an entity reference but metadata about validation errors for debugging purposes.
+
+    documentation:
+      - docs/architecture/REGISTRATION_REDUCER.md
+    ticket: OMN-1004
+  # ==========================================================================
+  # Handler Validation Error Model Exemptions (OMN-1091)
+  # ==========================================================================
+  # Handler validation error types are explicitly named per ticket requirements.
+  # rule_id and handler_id are human-readable semantic identifiers, not UUIDs.
+  - file_pattern: 'enum_handler_error_type\.py'
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      EnumHandlerErrorType is an enum for handler validation error types (CONTRACT_PARSE_ERROR, SECURITY_VALIDATION_ERROR, etc.). The "Handler" name is intentional per OMN-1091 spec.
+
+    documentation:
+      - CLAUDE.md (ONEX Architecture - Handler Types)
+    ticket: OMN-1091
+  - file_pattern: 'enum_handler_source_type\.py'
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      EnumHandlerSourceType is an enum for validation source types (CONTRACT, DESCRIPTOR, STATIC_ANALYSIS). The "Handler" name is intentional per OMN-1091 spec.
+
+    documentation:
+      - CLAUDE.md (ONEX Architecture - Handler Types)
+    ticket: OMN-1091
+  - file_pattern: 'model_handler_validation_error\.py'
+    violation_pattern: "Field 'rule_id' should use UUID"
+    reason: >
+      rule_id is a human-readable semantic identifier (e.g., "CONTRACT-001", "SECURITY-002") per ticket spec. Used for CI output and developer reference. Not a UUID.
+
+    documentation:
+      - docs/patterns/error_handling_patterns.md
+    ticket: OMN-1091
+  - file_pattern: 'model_handler_validation_error\.py'
+    method_pattern: "Function 'from_contract_error'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Factory method with many optional parameters for complete error construction. Parameters have defaults. Breaking into multiple calls would reduce usability.
+
+    documentation:
+      - docs/patterns/error_handling_patterns.md
+    ticket: OMN-1091
+  - file_pattern: 'model_handler_validation_error\.py'
+    method_pattern: "Function 'from_security_violation'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Factory method with many optional parameters for complete error construction. Parameters have defaults. Breaking into multiple calls would reduce usability.
+
+    documentation:
+      - docs/patterns/error_handling_patterns.md
+    ticket: OMN-1091
+  - file_pattern: 'model_handler_validation_error\.py'
+    method_pattern: "Function 'from_descriptor_error'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Factory method with many optional parameters for complete error construction. Parameters have defaults.
+
+    documentation:
+      - docs/patterns/error_handling_patterns.md
+    ticket: OMN-1091
+  - file_pattern: 'model_handler_validation_error\.py'
+    method_pattern: "Function 'from_architecture_error'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Factory method with many optional parameters for complete error construction. Parameters have defaults.
+
+    documentation:
+      - docs/patterns/error_handling_patterns.md
+    ticket: OMN-1091
+  - file_pattern: 'model_handler_identifier\.py'
+    violation_pattern: "Field 'handler_id' should use UUID"
+    reason: >
+      handler_id is a human-readable semantic identifier (e.g., "http-handler", "db-handler") per existing patterns. Not a UUID.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions - semantic identifiers vs UUIDs)
+    ticket: OMN-1091
+  # ==========================================================================
+  # Handler Contract Source Exemptions (OMN-1097)
+  # ==========================================================================
+  # handler_contract_source.py contains legitimate handler discovery code.
+  # The "Handler" in the class name refers to ONEX handler contracts, not an
+  # anti-pattern manager/helper class.
+  - file_pattern: 'handler_contract_source\.py'
+    class_pattern: "Class name 'HandlerContractSource'"
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      HandlerContractSource discovers handler contract YAML files from the filesystem. The "Handler" refers to ONEX handler contracts being discovered, not an anti-pattern manager class. This is legitimate handler infrastructure code.
+
+    documentation:
+      - docs/architecture/HANDLER_PROTOCOL_DRIVEN_ARCHITECTURE.md
+      - CLAUDE.md (ONEX Architecture - Handler Types)
+    ticket: OMN-1097
+  # ==========================================================================
+  # Handler Bootstrap Source Exemptions (OMN-1087)
+  # ==========================================================================
+  # HandlerBootstrapSource provides hardcoded handler descriptors for core
+  # infrastructure handlers. The "Handler" in the name refers to ONEX handler
+  # concepts, consistent with HandlerContractSource and HandlerPluginLoader.
+  #
+  # Pattern specificity note: Uses separate class_pattern + violation_pattern
+  # (not combined "Class name .* contains...") for precise targeting. All three
+  # patterns must match: exact filename, exact class name, and violation type.
+  # This is consistent with HandlerContractSource/HandlerPluginLoader exemptions.
+  - file_pattern: 'handler_bootstrap_source\.py'
+    class_pattern: "Class name 'HandlerBootstrapSource'"
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      HandlerBootstrapSource centralizes hardcoded handler registration for core infrastructure handlers (Consul, DB, HTTP, Vault). The "Handler" refers to ONEX handler concepts, consistent with HandlerContractSource. This is legitimate handler infrastructure code per OMN-1087.
+
+    documentation:
+      - docs/architecture/HANDLER_PROTOCOL_DRIVEN_ARCHITECTURE.md
+      - CLAUDE.md (ONEX Architecture - Handler Types)
+    ticket: OMN-1087
+  # ==========================================================================
+  # Handler Source Mode Exemptions (OMN-1095)
+  # ==========================================================================
+  # EnumHandlerSourceMode and HandlerSourceResolver are part of the handler
+  # source mode feature flag implementation. The "Handler" in the names refers
+  # to ONEX handler concepts (how handlers are discovered/loaded), consistent
+  # with HandlerBootstrapSource and HandlerContractSource.
+  - file_pattern: 'enum_handler_source_mode\.py'
+    class_pattern: "Class name 'EnumHandlerSourceMode'"
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      EnumHandlerSourceMode defines handler loading modes (BOOTSTRAP, CONTRACT, HYBRID). The "Handler" refers to ONEX handler concepts - how handlers are discovered and loaded at runtime. Consistent with HandlerBootstrapSource and HandlerContractSource naming.
+
+    documentation:
+      - docs/architecture/HANDLER_PROTOCOL_DRIVEN_ARCHITECTURE.md
+      - CLAUDE.md (ONEX Architecture - Handler Types)
+    ticket: OMN-1095
+  - file_pattern: 'handler_source_resolver\.py'
+    class_pattern: "Class name 'HandlerSourceResolver'"
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      HandlerSourceResolver implements per-handler identity resolution between bootstrap and contract sources. The "Handler" refers to ONEX handler concepts - resolving which handler source takes precedence. Consistent with HandlerBootstrapSource and HandlerContractSource naming.
+
+    documentation:
+      - docs/architecture/HANDLER_PROTOCOL_DRIVEN_ARCHITECTURE.md
+      - CLAUDE.md (ONEX Architecture - Handler Types)
+    ticket: OMN-1095
+  # ==========================================================================
+  # Handler Plugin Loader Exemptions (OMN-1132)
+  # ==========================================================================
+  # HandlerPluginLoader discovers and loads ONEX handlers from contract YAML files.
+  # The "Handler" in the name refers to ONEX handler contracts being loaded,
+  # not an anti-pattern manager/helper class.
+  - file_pattern: 'handler_plugin_loader\.py'
+    class_pattern: "Class name 'HandlerPluginLoader'"
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      HandlerPluginLoader loads ONEX handler contracts from YAML files. The "Handler" refers to ONEX handler contracts being discovered and loaded, not an anti-pattern manager class. This is legitimate handler infrastructure code.
+
+    documentation:
+      - docs/architecture/HANDLER_PROTOCOL_DRIVEN_ARCHITECTURE.md
+      - CLAUDE.md (ONEX Architecture - Handler Types)
+    ticket: OMN-1132
+  - file_pattern: 'handler_plugin_loader\.py'
+    class_pattern: "Class 'HandlerPluginLoader'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Plugin loader pattern requires multiple discovery methods (load_from_contract, load_from_directory, discover_and_load), security validation (_validate_namespace, _validate_file_security), contract parsing (_load_contract, _import_handler_class), and error handling methods. This is the standard plugin loader pattern consistent with ProjectorPluginLoader.
+
+    documentation:
+      - docs/patterns/handler_plugin_loader.md
+      - CLAUDE.md (Handler Plugin Loader Patterns)
+    ticket: OMN-1132
+  - file_pattern: 'protocol_handler_plugin_loader\.py'
+    class_pattern: "Class name 'ProtocolHandlerPluginLoader'"
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      ProtocolHandlerPluginLoader defines the interface for handler plugin loading. The "Handler" refers to ONEX handler contracts, consistent with HandlerPluginLoader.
+
+    documentation:
+      - docs/architecture/HANDLER_PROTOCOL_DRIVEN_ARCHITECTURE.md
+    ticket: OMN-1132
+  - file_pattern: 'model_loaded_handler\.py'
+    class_pattern: "Class name 'ModelLoadedHandler'"
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      ModelLoadedHandler represents metadata about a loaded ONEX handler contract. The "Handler" refers to ONEX handler concepts, not an anti-pattern.
+
+    documentation:
+      - docs/architecture/HANDLER_PROTOCOL_DRIVEN_ARCHITECTURE.md
+    ticket: OMN-1132
+  - file_pattern: 'model_handler_contract\.py'
+    class_pattern: "Class name 'ModelHandlerContract'"
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      ModelHandlerContract is the Pydantic schema for handler contract YAML files. The "Handler" refers to ONEX handler contracts, consistent with HandlerPluginLoader and ModelLoadedHandler.
+
+    documentation:
+      - docs/architecture/HANDLER_PROTOCOL_DRIVEN_ARCHITECTURE.md
+    ticket: OMN-1132
+  - file_pattern: 'model_handler_contract\.py'
+    violation_pattern: "Field 'handler_name' might reference an entity"
+    reason: >
+      handler_name is a human-readable identifier from the contract YAML (e.g., "auth-handler"). It's a semantic identifier, not an entity reference. Consistent with ModelLoadedHandler.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions - semantic identifiers)
+    ticket: OMN-1132
+  # ==========================================================================
+  # Contract Handler Discovery Exemptions (OMN-1133)
+  # ==========================================================================
+  # ContractHandlerDiscovery bridges HandlerPluginLoader with the BindingRegistry
+  # for automatic handler discovery from contracts. The "Handler" in the name
+  # refers to ONEX handler contracts being discovered, not an anti-pattern.
+  - file_pattern: 'contract_handler_discovery\.py'
+    class_pattern: "Class name 'ContractHandlerDiscovery'"
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      ContractHandlerDiscovery discovers ONEX handler contracts and registers them with the runtime. The "Handler" refers to ONEX handler contracts being discovered, consistent with HandlerPluginLoader.
+
+    documentation:
+      - docs/architecture/HANDLER_PROTOCOL_DRIVEN_ARCHITECTURE.md
+      - CLAUDE.md (Handler Plugin Loader Patterns)
+    ticket: OMN-1133
+  - file_pattern: 'protocol_handler_discovery\.py'
+    class_pattern: "Class name 'ProtocolHandlerDiscovery'"
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      ProtocolHandlerDiscovery defines the interface for handler discovery services. The "Handler" refers to ONEX handler contracts, consistent with ProtocolHandlerPluginLoader.
+
+    documentation:
+      - docs/architecture/HANDLER_PROTOCOL_DRIVEN_ARCHITECTURE.md
+    ticket: OMN-1133
+  - file_pattern: 'model_loaded_handler\.py'
+    violation_pattern: "Field 'handler_name' might reference an entity"
+    reason: >
+      handler_name is a human-readable identifier for the handler from the contract (e.g., "auth-handler"). It's a semantic identifier, not an entity reference.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions - semantic identifiers)
+    ticket: OMN-1132
+  - file_pattern: 'model_handler_descriptor\.py'
+    violation_pattern: "Field 'handler_id' should use UUID"
+    reason: >
+      handler_id in ModelHandlerDescriptor is a human-readable semantic identifier from handler contracts (e.g., "auth.handler"). Consistent with ModelHandlerIdentifier and other handler models. Not a UUID.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions - semantic identifiers vs UUIDs)
+    ticket: OMN-1097
+  - file_pattern: 'model_handler_security_policy\.py'
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      ModelHandlerSecurityPolicy defines security policies for ONEX handlers. The "Handler" refers to ONEX handler security constraints, not an anti-pattern manager class. Part of the two-layer security validation system (OMN-1098).
+
+    documentation:
+      - docs/architecture/HANDLER_PROTOCOL_DRIVEN_ARCHITECTURE.md
+    ticket: OMN-1098
+  # LocalHandler validator models - OMN-743
+  # These models validate LocalHandler import restrictions in production code.
+  # The "Handler" in the name refers to the specific LocalHandler class being
+  # validated, not an anti-pattern handler class.
+  - file_pattern: 'model_localhandler_violation\.py'
+    class_pattern: "Class name 'ModelLocalHandlerViolation'"
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      ModelLocalHandlerViolation is a validation result model for detecting forbidden LocalHandler imports. The "Handler" refers to the omnibase_core.handlers.LocalHandler class being validated against, not an anti-pattern manager class.
+
+    documentation:
+      - CLAUDE.md (LocalHandler dev-only enforcement)
+    ticket: OMN-743
+  - file_pattern: 'model_localhandler_validation_result\.py'
+    class_pattern: "Class name 'ModelLocalHandlerValidationResult'"
+    violation_pattern: "contains anti-pattern 'Handler'"
+    reason: >
+      ModelLocalHandlerValidationResult is the aggregate validation result for LocalHandler import checking. The "Handler" refers to the omnibase_core.handlers.LocalHandler class being validated against, not an anti-pattern manager class.
+
+    documentation:
+      - CLAUDE.md (LocalHandler dev-only enforcement)
+    ticket: OMN-743
+  - file_pattern: 'validation_aggregator\.py'
+    class_pattern: "Class 'ValidationAggregator'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Aggregator class requires multiple methods for comprehensive error management: collection (add_error, add_errors), properties (has_errors, has_blocking_errors, counts), grouping (by_type, by_source), formatting (console, ci, summary), and lifecycle (raise_if_blocking, clear). This is an established aggregator pattern.
+
+    documentation:
+      - docs/patterns/error_handling_patterns.md
+    ticket: OMN-1091
+  - file_pattern: 'validator_security\.py'
+    method_pattern: "Function 'convert_to_validation_error'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Conversion function requires multiple context parameters for complete error construction. Parameters are distinct required contexts for error reporting.
+
+    documentation:
+      - docs/patterns/security_patterns.md
+    ticket: OMN-1091
+  # ==========================================================================
+  # Service Discovery Node Exemptions (OMN-1131)
+  # ==========================================================================
+  # The service discovery node is a domain-specific infrastructure component that
+  # integrates with external service discovery systems (Consul, Kubernetes).
+  # The term "Service" is fundamental to the service discovery domain and cannot
+  # be replaced with alternative terminology without losing semantic clarity.
+  # HashiCorp Consul, Kubernetes, and all major service discovery systems use
+  # "service" as the canonical term for discoverable network endpoints.
+  - file_pattern: 'node_service_discovery_effect/node\.py'
+    class_pattern: "Class name 'NodeServiceDiscoveryEffect'"
+    violation_pattern: "contains anti-pattern 'Service'"
+    reason: >
+      NodeServiceDiscoveryEffect is the ONEX node for service discovery operations. "Service" is the canonical domain term from HashiCorp Consul and Kubernetes service discovery APIs.
+
+    documentation:
+      - HashiCorp Consul Service Discovery API (https://developer.hashicorp.com/consul/api-docs/agent/service)
+      - Kubernetes Service Discovery (https://kubernetes.io/docs/concepts/services-networking/service/)
+    ticket: OMN-1131
+  - file_pattern: 'node_service_discovery_effect/models/model_service_info\.py'
+    class_pattern: "Class name 'ModelServiceInfo'"
+    violation_pattern: "contains anti-pattern 'Service'"
+    reason: >
+      ModelServiceInfo represents service metadata from discovery systems. "Service" is the canonical domain term.
+
+    documentation:
+      - HashiCorp Consul Service Discovery API (https://developer.hashicorp.com/consul/api-docs/agent/service)
+      - Kubernetes Service Discovery (https://kubernetes.io/docs/concepts/services-networking/service/)
+    ticket: OMN-1131
+  - file_pattern: 'node_service_discovery_effect/models/model_service_info\.py'
+    violation_pattern: "Field 'service_name' might reference an entity"
+    reason: >
+      service_name is the canonical Consul/K8s service identifier. This is infrastructure configuration, not an entity reference.
+
+    documentation:
+      - HashiCorp Consul Service Discovery API (https://developer.hashicorp.com/consul/api-docs/agent/service)
+      - CLAUDE.md (Model Field Naming - infrastructure identifiers)
+    ticket: OMN-1131
+  - file_pattern: 'node_service_discovery_effect/models/enum_service_discovery_operation\.py'
+    class_pattern: "Class name 'EnumServiceDiscoveryOperation'"
+    violation_pattern: "contains anti-pattern 'Service'"
+    reason: >
+      EnumServiceDiscoveryOperation defines operations for service discovery (REGISTER, DEREGISTER, DISCOVER). "Service" is the canonical domain term.
+
+    documentation:
+      - HashiCorp Consul Service Discovery API (https://developer.hashicorp.com/consul/api-docs/agent/service)
+      - Kubernetes Service Discovery (https://kubernetes.io/docs/concepts/services-networking/service/)
+    ticket: OMN-1131
+  - file_pattern: 'node_service_discovery_effect/models/model_service_discovery_health_check_details\.py'
+    class_pattern: "Class name 'ModelServiceDiscoveryHealthCheckDetails'"
+    violation_pattern: "contains anti-pattern 'Service'"
+    reason: >
+      ModelServiceDiscoveryHealthCheckDetails contains health check configuration for service discovery. "Service" is the canonical domain term.
+
+    documentation:
+      - HashiCorp Consul Health Checks (https://developer.hashicorp.com/consul/docs/services/usage/checks)
+      - Kubernetes Probes (https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)
+    ticket: OMN-1131
+  - file_pattern: 'node_service_discovery_effect/models/model_service_registration\.py'
+    class_pattern: "Class name 'ModelServiceRegistration'"
+    violation_pattern: "contains anti-pattern 'Service'"
+    reason: >
+      ModelServiceRegistration is the input model for registering services in discovery systems. "Service" is the canonical domain term.
+
+    documentation:
+      - HashiCorp Consul Service Registration (https://developer.hashicorp.com/consul/api-docs/agent/service#register-service)
+      - Kubernetes Service Discovery (https://kubernetes.io/docs/concepts/services-networking/service/)
+    ticket: OMN-1131
+  - file_pattern: 'node_service_discovery_effect/models/model_service_registration\.py'
+    violation_pattern: "Field 'service_name' might reference an entity"
+    reason: >
+      service_name is the canonical Consul/K8s service identifier. This is infrastructure configuration, not an entity reference.
+
+    documentation:
+      - HashiCorp Consul Service Registration (https://developer.hashicorp.com/consul/api-docs/agent/service#register-service)
+      - CLAUDE.md (Model Field Naming - infrastructure identifiers)
+    ticket: OMN-1131
+  - file_pattern: 'node_service_discovery_effect/models/model_service_discovery_health_check_result\.py'
+    class_pattern: "Class name 'ModelServiceDiscoveryHealthCheckResult'"
+    violation_pattern: "contains anti-pattern 'Service'"
+    reason: >
+      ModelServiceDiscoveryHealthCheckResult contains health check results from service discovery. "Service" is the canonical domain term.
+
+    documentation:
+      - HashiCorp Consul Health Checks (https://developer.hashicorp.com/consul/docs/services/usage/checks)
+      - Kubernetes Probes (https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)
+    ticket: OMN-1131
+  - file_pattern: 'node_service_discovery_effect/registry/registry_infra_service_discovery\.py'
+    class_pattern: "Class name 'RegistryInfraServiceDiscovery'"
+    violation_pattern: "contains anti-pattern 'Service'"
+    reason: >
+      RegistryInfraServiceDiscovery is the DI registry for service discovery handlers. "Service" is the canonical domain term.
+
+    documentation:
+      - docs/patterns/container_dependency_injection.md (Registry patterns)
+      - HashiCorp Consul Service Discovery API (https://developer.hashicorp.com/consul/api-docs/agent/service)
+    ticket: OMN-1131
+  - file_pattern: 'handlers/registration_storage/handler_registration_storage_postgres\.py'
+    method_pattern: "Function '__init__'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      PostgreSQL handler requires multiple configuration parameters: pool, host, port, database, user, password, min_size, max_size, timeout, circuit_breaker_config. These are standard database connection parameters.
+
+    documentation:
+      - asyncpg Pool Configuration (https://magicstack.github.io/asyncpg/current/api/index.html#connection-pools)
+    ticket: OMN-1131
+  - file_pattern: 'handlers/service_discovery/handler_service_discovery_consul\.py'
+    method_pattern: "Function '__init__'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Consul handler requires multiple configuration parameters: consul_client, token, scheme, host, port, dc, circuit_breaker_config. These are standard Consul connection parameters.
+
+    documentation:
+      - HashiCorp Consul API Configuration (https://developer.hashicorp.com/consul/api-docs)
+    ticket: OMN-1131
+  - file_pattern: 'handlers/service_discovery/models/model_service_info\.py'
+    violation_pattern: "Field 'service_name' might reference an entity"
+    reason: >
+      service_name is the canonical Consul/K8s service identifier. This is infrastructure configuration, not an entity reference.
+
+    documentation:
+      - HashiCorp Consul Service Discovery API (https://developer.hashicorp.com/consul/api-docs/agent/service)
+      - CLAUDE.md (Model Field Naming - infrastructure identifiers)
+    ticket: OMN-1131
+  # ==========================================================================
+  # Architecture Validator AST Exemptions (OMN-1099)
+  # ==========================================================================
+  # Python ast.NodeVisitor convention uses visit_ClassDef, visit_Call, visit_Name, etc.
+  # These method names are REQUIRED by the ast module - they cannot be renamed.
+  # Reference: https://docs.python.org/3/library/ast.html#ast.NodeVisitor
+  #
+  # This is a GENERAL exemption for ALL visit_* methods in ANY Python file,
+  # as AST visitor patterns are used throughout the codebase for static analysis.
+  - file_pattern: '.*\.py'
+    violation_pattern: "Function name 'visit_\\w+' should use snake_case"
+    reason: >
+      Python ast.NodeVisitor convention. visit_* methods (visit_ClassDef, visit_Call, visit_Name, etc.) are standard AST visitor method names that the ast module dispatches to. They cannot be renamed without breaking the visitor pattern.
+
+    documentation:
+      - Python ast.NodeVisitor (https://docs.python.org/3/library/ast.html)
+      - PEP 8 - Exception for stdlib compatibility
+    ticket: OMN-1099
+  # HandlerPublishingVisitor is a class that validates handler publishing constraints.
+  # The "Handler" name is appropriate because it IS validating handler behavior.
+  - file_pattern: 'validator_no_handler_publishing\.py'
+    violation_pattern: "Class name .* contains anti-pattern 'Handler'"
+    reason: >
+      HandlerPublishingVisitor is an AST visitor class that validates handler publishing constraints. The "Handler" name is intentional and appropriate because it validates that handlers do NOT have direct event bus access. This is a validator class, not a handler implementation.
+
+    documentation:
+      - CLAUDE.md (Handler No-Publish Constraint)
+      - docs/patterns/security_patterns.md
+    ticket: OMN-1099
+  # ==========================================================================
+  # Validation Result Model Exemptions (OMN-1104)
+  # ==========================================================================
+  # field_name in ModelValidationResult is a validation field path identifier,
+  # not an entity reference. It represents which field in the validated object
+  # failed validation (e.g., "node_id", "node_type").
+  - file_pattern: 'model_validation_result\.py'
+    violation_pattern: "Field 'field_name' might reference an entity"
+    reason: >
+      field_name is a validation field path (e.g., "node_id"), not an entity reference. It indicates which field in the validated object failed validation.
+
+    documentation:
+      - docs/patterns/error_handling_patterns.md
+    ticket: OMN-1104
+  # ==========================================================================
+  # Consul Registration Payload Exemptions (OMN-1104)
+  # ==========================================================================
+  # service_id and service_name are Consul native formats (strings), not UUIDs
+  # or entity references. Consul service registry uses string identifiers.
+  - file_pattern: 'model_payload_consul_register\.py'
+    violation_pattern: "Field 'service_id' should use UUID"
+    reason: >
+      service_id is Consul's native string format for service identifiers. Consul does not use UUIDs for service identification - it uses human-readable string IDs.
+
+    documentation:
+      - docs/architecture/REGISTRATION_ORCHESTRATOR_ARCHITECTURE.md
+      - HashiCorp Consul Service Discovery API (https://developer.hashicorp.com/consul/api-docs/agent/service)
+    ticket: OMN-1104
+  - file_pattern: 'model_payload_consul_register\.py'
+    violation_pattern: "Field 'service_name' might reference an entity"
+    reason: >
+      service_name is a display string for the Consul service catalog, not an entity reference. It's the human-readable name shown in Consul's UI.
+
+    documentation:
+      - docs/architecture/REGISTRATION_ORCHESTRATOR_ARCHITECTURE.md
+      - HashiCorp Consul Service Discovery API (https://developer.hashicorp.com/consul/api-docs/agent/service)
+    ticket: OMN-1104
+  # ==========================================================================
+  # Architecture Validator Semantic ID Exemptions (OMN-1138)
+  # ==========================================================================
+  # Architecture validation rules use semantic string identifiers (e.g.,
+  # 'NO_HANDLER_PUBLISHING', 'PURE_REDUCERS') rather than UUIDs. These are
+  # human-readable rule codes similar to error codes, not database entity IDs.
+  - file_pattern: 'model_rule_check_result\.py'
+    violation_pattern: "Field 'rule_id' should use UUID"
+    reason: >
+      rule_id is a semantic identifier for architecture rules (e.g., 'NO_HANDLER_PUBLISHING'). These are human-readable rule codes like error codes, not database entity UUIDs.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions - semantic identifiers vs UUIDs)
+    ticket: OMN-1138
+  - file_pattern: 'model_architecture_violation\.py'
+    violation_pattern: "Field 'rule_id' should use UUID"
+    reason: >
+      rule_id is a semantic identifier for architecture rules (e.g., 'NO_HANDLER_PUBLISHING'). These are human-readable rule codes, not database entity UUIDs.
+
+    documentation:
+      - CLAUDE.md (Registry Naming Conventions - semantic identifiers vs UUIDs)
+    ticket: OMN-1138
+  - file_pattern: 'model_architecture_violation\.py'
+    violation_pattern: "Field 'rule_name' might reference an entity"
+    reason: >
+      rule_name is a human-readable display name for the rule (e.g., 'No Handler Publishing'). It's a static description, not a reference to a named entity.
+
+    documentation:
+      - CLAUDE.md (Model Field Naming - display names vs entity references)
+    ticket: OMN-1138
+  - file_pattern: 'model_architecture_violation\.py'
+    violation_pattern: "Field 'target_name' might reference an entity"
+    reason: >
+      target_name is dynamically derived from type(target).__name__ during validation. It's a runtime-computed description for logging, not an entity reference.
+
+    documentation:
+      - CLAUDE.md (Model Field Naming - computed display names)
+    ticket: OMN-1138
+  # ==========================================================================
+  # ProjectorValidationError Exemptions (OMN-1168)
+  # ==========================================================================
+  # Validation error class requires multiple context parameters for complete
+  # error information: error_type, contract_path, message, remediation_hint,
+  # and correlation_id. These are distinct required contexts for error reporting.
+  - file_pattern: 'model_projector_validation_error\.py'
+    method_pattern: "Function '__init__'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      Validation error class requires multiple contextual parameters for debugging: error_type, contract_path, message, remediation_hint, correlation_id. These are distinct error context fields needed for comprehensive error reporting and graceful mode error collection.
+
+    documentation:
+      - docs/patterns/error_handling_patterns.md
+      - CLAUDE.md (Infrastructure Error Patterns)
+    ticket: OMN-1168
+  # ==========================================================================
+  # ProjectorPluginLoader Exemptions (OMN-1168)
+  # ==========================================================================
+  # Plugin loader pattern requires multiple discovery methods:
+  # - load_from_contract, load_from_directory, discover_and_load
+  # - Security validation methods (_validate_file_security, _sanitize_path)
+  # - Contract parsing (_load_contract, _parse_yaml)
+  # - Error handling (discover_with_errors, graceful mode support)
+  - file_pattern: 'projector_plugin_loader\.py'
+    class_pattern: "Class 'ProjectorPluginLoader'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Plugin loader pattern requires multiple discovery methods (load_from_contract, load_from_directory, discover_and_load), security validation, contract parsing, and error handling methods. Mirrors handler_contract_source.py pattern.
+
+    documentation:
+      - src/omnibase_infra/runtime/handler_contract_source.py (reference pattern)
+    ticket: OMN-1168
+  - file_pattern: 'projector_plugin_loader\.py'
+    method_pattern: "Function '__init__'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      ProjectorPluginLoader.__init__ requires multiple configuration parameters for security controls (allowed_namespaces), observability (correlation_id), and plugin discovery settings. Mirrors HandlerPluginLoader pattern which has similar constructor signature.
+
+    documentation:
+      - src/omnibase_infra/runtime/handler_plugin_loader.py (reference pattern)
+      - docs/patterns/handler_plugin_loader.md (security model)
+    ticket: OMN-1316
+  # ==========================================================================
+  # ProjectorShell Exemptions (OMN-1169)
+  # ==========================================================================
+  # ProjectorShell implements ProtocolEventProjector protocol which requires:
+  # - Protocol properties (projector_id, aggregate_type, consumed_events, contract, is_placeholder)
+  # - Core methods (project, get_state, get_states, partial_update, upsert_partial)
+  # - SQL execution modes handled by MixinProjectorSqlOperations
+  # - Value extraction (_extract_values, _resolve_path, _get_event_type, _execute_projection)
+  # - Notification integration (via MixinProjectorNotificationPublishing)
+  # Total: 11 methods, all cohesive to the contract-driven projector pattern.
+  # OMN-1139: Added notification publishing support via mixin composition.
+  # NOTE: Pattern anchored with src/omnibase_infra/runtime/ prefix to match only
+  # the production file at src/omnibase_infra/runtime/projector_shell.py.
+  # This prevents matching test files in tests/unit/runtime/ or tests/integration/runtime/.
+  - file_pattern: 'src/omnibase_infra/runtime/projector_shell\.py'
+    class_pattern: "Class 'ProjectorShell'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Implements ProtocolEventProjector protocol requiring protocol properties (projector_id, aggregate_type, consumed_events, is_placeholder), core methods (project, get_state), three SQL execution modes (_upsert, _insert, _append), value extraction helpers (_extract_values, _resolve_path, _get_event_type), and utility method (_parse_row_count). All methods are cohesive to the contract-driven projector pattern.
+
+    documentation:
+      - src/omnibase_infra/runtime/projector_shell.py (class docstring)
+      - omnibase_spi/protocols/projectors/protocol_event_projector.py (protocol definition)
+    ticket: OMN-1169
+  # ==========================================================================
+  # Qdrant Handler Model Exemptions (OMN-1142)
+  # ==========================================================================
+  # collection_name is a Qdrant-native identifier, not an entity reference.
+  # Qdrant uses string collection names as the primary way to identify and
+  # access vector collections. This matches the qdrant-client API design.
+  - file_pattern: 'model_qdrant_upsert_payload\.py'
+    violation_pattern: "Field 'collection_name' might reference an entity"
+    reason: >
+      collection_name is a Qdrant collection identifier (e.g., 'embeddings', 'documents'). Qdrant uses string collection names as the primary API identifier, not UUIDs. This matches the qdrant-client library design.
+
+    documentation:
+      - https://qdrant.tech/documentation/concepts/collections/
+      - src/omnibase_infra/handlers/handler_qdrant.py
+    ticket: OMN-1142
+  - file_pattern: 'model_qdrant_collection_payload\.py'
+    violation_pattern: "Field 'collection_name' might reference an entity"
+    reason: >
+      collection_name is a Qdrant collection identifier (e.g., 'embeddings', 'documents'). Qdrant uses string collection names as the primary API identifier, not UUIDs. This matches the qdrant-client library design.
+
+    documentation:
+      - https://qdrant.tech/documentation/concepts/collections/
+      - src/omnibase_infra/handlers/handler_qdrant.py
+    ticket: OMN-1142
+  - file_pattern: 'model_qdrant_search_payload\.py'
+    violation_pattern: "Field 'collection_name' might reference an entity"
+    reason: >
+      collection_name is a Qdrant collection identifier (e.g., 'embeddings', 'documents'). Qdrant uses string collection names as the primary API identifier, not UUIDs. This matches the qdrant-client library design.
+
+    documentation:
+      - https://qdrant.tech/documentation/concepts/collections/
+      - src/omnibase_infra/handlers/handler_qdrant.py
+    ticket: OMN-1142
+  - file_pattern: 'model_qdrant_delete_payload\.py'
+    violation_pattern: "Field 'collection_name' might reference an entity"
+    reason: >
+      collection_name is a Qdrant collection identifier (e.g., 'embeddings', 'documents'). Qdrant uses string collection names as the primary API identifier, not UUIDs. This matches the qdrant-client library design.
+
+    documentation:
+      - https://qdrant.tech/documentation/concepts/collections/
+      - src/omnibase_infra/handlers/handler_qdrant.py
+    ticket: OMN-1142
+  # ==========================================================================
+  # Projector Schema Model Exemptions (OMN-1168)
+  # ==========================================================================
+  # table_name is a standard database identifier, not an entity reference.
+  # This pattern is ubiquitous in database-related models.
+  # NOTE: Projector models are temporarily in omnibase_infra until omnibase_core
+  # provides canonical projector model types.
+  - file_pattern: 'model_projector_schema\.py'
+    violation_pattern: "Field 'table_name' might reference an entity"
+    reason: >
+      table_name is a PostgreSQL table identifier (e.g., 'node_registrations'), not an entity reference. Standard database schema pattern. Note: Projector models are temporarily located in omnibase_infra until omnibase_core provides canonical projector model types.
+
+    documentation:
+      - PostgreSQL CREATE TABLE syntax
+      - src/omnibase_infra/schemas/schema_registration_projection.sql (example usage)
+      - src/omnibase_infra/models/projectors/model_projector_schema.py (ModelProjectorSchema defines table_name as identifier, temporary location in omnibase_infra)
+    ticket: OMN-1168
+  # ==========================================================================
+  # SecretResolver Exemptions (OMN-764)
+  # ==========================================================================
+  # SecretResolver is a centralized secret resolution service with cohesive
+  # functionality: sync/async resolution, caching, introspection, and refresh.
+  # The 18 methods form a complete API for secret management:
+  # - Primary API (4): get_secret, get_secrets, get_secret_async, get_secrets_async
+  # - Cache management (3): refresh, refresh_all, get_cache_stats
+  # - Introspection (2): list_configured_secrets, get_source_info
+  # - Internal helpers (9): resolution, caching, path conversion
+  - file_pattern: 'secret_resolver\.py'
+    class_pattern: "Class 'SecretResolver'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      SecretResolver provides centralized secret resolution with sync/async APIs, caching with TTL, and safe introspection. The 18 methods are cohesive: 4 primary API methods, 3 cache management, 2 introspection, and 9 internal helpers. Splitting would fragment a unified secret management interface.
+
+    documentation:
+      - docs/patterns/secret_resolver.md
+      - CLAUDE.md (Infrastructure Patterns - SecretResolver)
+    ticket: OMN-764
+  # logical_name is a secret identifier using dotted path convention (e.g., "database.postgres.password")
+  # It is NOT an entity reference - it's a lookup key for secret resolution.
+  - file_pattern: 'model_secret_source_info\.py'
+    violation_pattern: "Field 'logical_name' might reference an entity"
+    reason: >
+      logical_name is a secret identifier using dotted path convention (e.g., "database.postgres.password"), not an entity reference. It's a lookup key for the SecretResolver, similar to how env var names or Vault paths identify secrets.
+
+    documentation:
+      - docs/patterns/secret_resolver.md (Naming Conventions section)
+    ticket: OMN-764
+  - file_pattern: 'model_secret_mapping\.py'
+    violation_pattern: "Field 'logical_name' might reference an entity"
+    reason: >
+      logical_name is a secret identifier using dotted path convention (e.g., "database.postgres.password"), not an entity reference. It's a lookup key for mapping secrets to their sources.
+
+    documentation:
+      - docs/patterns/secret_resolver.md (Naming Conventions section)
+    ticket: OMN-764
+  - file_pattern: 'model_cached_secret\.py'
+    violation_pattern: "Field 'logical_name' might reference an entity"
+    reason: >
+      logical_name is a secret identifier using dotted path convention (e.g., "database.postgres.password"), not an entity reference. It's stored in the cache to track which secret this cached value represents.
+
+    documentation:
+      - docs/patterns/secret_resolver.md (Naming Conventions section)
+    ticket: OMN-764
+  # ==========================================================================
+  # Observability Layer Exemptions (OMN-767)
+  # ==========================================================================
+  # The observability layer implements hot-path sinks and hooks that require
+  # comprehensive interfaces for metrics, logging, and timing operations.
+  # Per CLAUDE.md "Handlers own lifecycle, sinks own hot path" principle.
+  - file_pattern: 'sink_logging_structured\.py'
+    class_pattern: "Class 'SinkLoggingStructured'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Hot-path logging sink requires comprehensive interface for ProtocolHotPathLoggingSink compliance: emit(), flush(), buffer management, and output formatting. Methods are protocol-mandated.
+
+    documentation:
+      - CLAUDE.md (Observability Layer - Handlers own lifecycle, sinks own hot path)
+    ticket: OMN-767
+  - file_pattern: 'hook_observability\.py'
+    class_pattern: "Class 'HookObservability'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      Pipeline observability hook requires comprehensive interface for cross-cutting concerns: before/after operation tracking, metrics integration, context management, retry tracking, and circuit breaker state changes.
+
+    documentation:
+      - CLAUDE.md (Observability Layer - Handlers own lifecycle, sinks own hot path)
+    ticket: OMN-767
+  - file_pattern: 'model_metrics_handler_config\.py'
+    violation_pattern: "Field 'job_name' might reference an entity"
+    reason: >
+      job_name is a Prometheus Pushgateway configuration value (human-readable string identifier), not an entity reference. It follows Prometheus naming conventions.
+
+    documentation:
+      - Prometheus Pushgateway documentation
+    ticket: OMN-767
+  # ==========================================================================
+  # BindingConfigResolver Exemptions (OMN-765)
+  # ==========================================================================
+  # BindingConfigResolver is a centralized configuration resolution service with
+  # cohesive functionality: sync/async resolution, multi-source support, caching,
+  # and environment overrides. Similar to SecretResolver, the methods form a
+  # complete API for configuration management:
+  # - Primary API (4): resolve, resolve_async, resolve_many, resolve_many_async
+  # - Cache management (4): invalidate, invalidate_all, get_cache_stats, cleanup
+  # - Internal helpers (13): source loading, env overrides, vault refs, validation
+  - file_pattern: 'binding_config_resolver\.py'
+    class_pattern: "Class 'BindingConfigResolver'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      BindingConfigResolver provides centralized configuration resolution with sync/async APIs, TTL-based caching, and multi-source support (file, env, vault). Similar to SecretResolver, the 21 methods are cohesive: 4 primary resolution API methods, 4 cache management, and 13 internal helpers for source loading, environment overrides, vault reference resolution, and validation. Splitting would fragment a unified configuration management interface.
+
+    documentation:
+      - docs/patterns/binding_config_resolver.md
+    ticket: OMN-765
+  # ==========================================================================
+  # HandlerMCP Method Count Exemption (OMN-1282)
+  # ==========================================================================
+  # MCP handler is a complex infrastructure component requiring many methods:
+  # - 4 ProtocolHandler methods (initialize, shutdown, execute, health_check)
+  # - 2 factory methods for route handlers (_create_health_endpoint, _create_tools_list_endpoint)
+  # - 2 server lifecycle methods (_start_http_server, _stop_http_server)
+  # - 3 execution/operation methods (_run_server, _execute_tool_operation, _execute_describe)
+  # Complexity is inherent to MCP protocol requirements and uvicorn server management.
+  - file_pattern: 'handler_mcp\.py'
+    class_pattern: "Class 'HandlerMCP'"
+    violation_pattern: 'has \d+ methods'
+    reason: >
+      HandlerMCP is a complex infrastructure handler implementing MCP protocol with internal uvicorn server lifecycle. The 11 methods are cohesive: 4 ProtocolHandler interface methods, 2 factory methods for Starlette route handlers (explicit closure capture), 2 server lifecycle methods (start/stop), and 3 operation methods. Splitting would fragment the unified MCP server abstraction.
+
+    documentation:
+      - CLAUDE.md (Handler Plugin Loader Patterns)
+    ticket: OMN-1282
+  # ==========================================================================
+  # Registry API Models - service_name Exemptions (OMN-1278)
+  # ==========================================================================
+  # service_name in registry API models is the Consul service name for discovery,
+  # NOT an entity reference. It's an external Consul identifier.
+  - file_pattern: 'services/registry_api/models/model_registry_node_view\.py'
+    violation_pattern: "Field 'service_name' might reference an entity"
+    reason: >
+      service_name is the Consul service name for service discovery (e.g., "onex-effect-abc123"). This is an external Consul identifier, NOT an ONEX entity reference. The node_id field provides the UUID identifier; service_name is how the node appears in Consul's catalog.
+
+    documentation:
+      - CLAUDE.md (Type Annotation Conventions)
+      - Consul service discovery documentation
+    ticket: OMN-1278
+  - file_pattern: 'services/registry_api/models/model_registry_instance_view\.py'
+    violation_pattern: "Field 'service_name' might reference an entity"
+    reason: >
+      service_name is the Consul service name for live instance discovery (e.g., "my-service"). This is an external Consul identifier, NOT an ONEX entity reference. The node_id and service_id fields provide UUID identifiers; service_name is the Consul catalog name.
+
+    documentation:
+      - CLAUDE.md (Type Annotation Conventions)
+      - Consul service discovery documentation
+    ticket: OMN-1278
+    # ==========================================================================
+  # ==========================================================================
+  # OperationBindingResolver.resolve() requires multiple parameters for binding
+  # resolution: operation, bindings_subcontract, envelope, context, correlation_id.
+  # These are distinct inputs required for the resolution process.
+  - file_pattern: 'binding_resolver\.py'
+    # Declarative Operation Bindings Exemptions (OMN-1518)
+
+    method_pattern: "Function 'resolve'"
+    violation_pattern: 'has \d+ parameters'
+    reason: >
+      resolve() requires distinct parameters for binding resolution: operation name, bindings subcontract, envelope data, optional context, and correlation_id for error context. Breaking into multiple calls would require intermediate state or complex configuration objects that reduce API clarity.
+
+    documentation:
+      - docs/decisions/adr-declarative-operation-bindings.md
+    ticket: OMN-1518
+  # parameter_name in binding models is the handler parameter name being bound,
+  # NOT an entity reference. It's a simple string identifier for the target parameter.
+  - file_pattern: 'model_operation_binding\.py'
+    violation_pattern: "Field 'parameter_name' might reference an entity"
+    reason: >
+      parameter_name is the target handler input field name (e.g., "correlation_id", "sql"). This is a Python function parameter name, NOT an entity reference. It maps to the handler's function signature parameter.
+
+    documentation:
+      - docs/decisions/adr-declarative-operation-bindings.md
+    ticket: OMN-1518
+  - file_pattern: 'model_parsed_binding\.py'
+    violation_pattern: "Field 'parameter_name' might reference an entity"
+    reason: >
+      parameter_name is the target handler input field name (e.g., "correlation_id", "sql"). This is a Python function parameter name, NOT an entity reference. It maps to the handler's function signature parameter.
+
+    documentation:
+      - docs/decisions/adr-declarative-operation-bindings.md
+    ticket: OMN-1518
+  # operation_name in ModelBindingResolutionResult is the operation that was
+  # resolved (e.g., "db.query"), NOT an entity reference. It's a dispatch key.
+  - file_pattern: 'model_binding_resolution_result\.py'
+    violation_pattern: "Field 'operation_name' might reference an entity"
+    reason: >
+      operation_name is the dispatch operation key that was resolved (e.g., "db.query", "consul.register"). This is a routing identifier, NOT an entity reference. It identifies which operation's bindings were resolved.
+
+    documentation:
+      - docs/decisions/adr-declarative-operation-bindings.md
+    ticket: OMN-1518
+  # ==========================================================================
+  # ModelNodeIdentity node_name Exemption (OMN-1602)
+  # ==========================================================================
+  # node_name in ModelNodeIdentity is a canonical identifier for the node within
+  # the ONEX infrastructure, NOT a foreign key reference to another entity.
+  # It is one of the four dimensions (env, service, node_name, version) that
+  # uniquely identify a node instance.
+  - file_pattern: 'model_node_identity\.py'
+    violation_pattern: "Field 'node_name' might reference an entity"
+    reason: >
+      node_name is a canonical identifier (e.g., "claude_hook_event_effect") that uniquely identifies a node within its service. It is NOT a foreign key reference - it is the node's own name from its contract. Combined with env, service, and version, it forms the node's identity.
+
+    documentation:
+      - docs/architecture/REGISTRATION_ORCHESTRATOR_ARCHITECTURE.md
+    ticket: OMN-1602
+  # ==========================================================================
+  # Emit Daemon Field Type Exemptions (OMN-1610)
+  # ==========================================================================
+  # Fields that are intentionally str instead of UUID for specific reasons
+  - file_pattern: 'emit_daemon/queue\.py'
+    violation_pattern: "Field 'event_id' should use UUID type instead of str"
+    reason: event_id is a string representation of a UUID for JSON serialization compatibility.
+    documentation:
+      - src/omnibase_infra/runtime/emit_daemon/queue.py
+    ticket: OMN-1610
+  - file_pattern: 'emit_daemon/model_daemon_response\.py'
+    violation_pattern: "Field 'event_id' should use UUID type instead of str"
+    reason: event_id is returned as a string in the daemon protocol for JSON serialization compatibility. Matches queue.py event_id.
+    documentation:
+      - src/omnibase_infra/runtime/emit_daemon/model_daemon_response.py
+    ticket: OMN-1610
+  - file_pattern: 'emit_daemon/config\.py'
+    violation_pattern: "Field 'kafka_client_id' should use UUID type instead of str"
+    reason: kafka_client_id is a Kafka client identifier string, not a UUID.
+    documentation:
+      - Kafka client.id documentation
+    ticket: OMN-1610
+  # ==========================================================================
+  # Contract Registry Reducer Handler Exemptions (OMN-1653)
+  # ==========================================================================
+  # Pure reducer handlers follow the pattern: (self, state, event, topic, partition, offset)
+  # This 6-parameter signature is standard for event-sourced reducers that need:
+  # - state: immutable input state
+  # - event: typed domain event
+  # - topic/partition/offset: Kafka position for idempotency tracking
+  - file_pattern: 'nodes/contract_registry_reducer/reducer\.py'
+    method_pattern: '_on_contract_registered'
+    violation_pattern: 'has 6 parameters'
+    reason: >
+      Standard reducer handler signature for event-sourced reducers. The 6 parameters provide: self, state (immutable input), event (typed domain event), and Kafka position (topic/partition/offset) for idempotency tracking. This is the canonical pattern for ONEX reducers.
+
+    documentation:
+      - CLAUDE.md (Node Archetypes - NodeReducer)
+      - docs/patterns/reducer_pattern.md
+    ticket: OMN-1653
+  - file_pattern: 'nodes/contract_registry_reducer/reducer\.py'
+    method_pattern: '_on_contract_deregistered'
+    violation_pattern: 'has 6 parameters'
+    reason: Same as _on_contract_registered - standard reducer handler signature.
+    documentation:
+      - CLAUDE.md (Node Archetypes - NodeReducer)
+    ticket: OMN-1653
+  - file_pattern: 'nodes/contract_registry_reducer/reducer\.py'
+    method_pattern: '_on_heartbeat'
+    violation_pattern: 'has 6 parameters'
+    reason: Same as _on_contract_registered - standard reducer handler signature.
+    documentation:
+      - CLAUDE.md (Node Archetypes - NodeReducer)
+    ticket: OMN-1653
+  - file_pattern: 'nodes/contract_registry_reducer/reducer\.py'
+    method_pattern: '_on_runtime_tick'
+    violation_pattern: 'has 6 parameters'
+    reason: Same as _on_contract_registered - standard reducer handler signature.
+    documentation:
+      - CLAUDE.md (Node Archetypes - NodeReducer)
+    ticket: OMN-1653
+  # Contract ID is a derived natural key (node_name:major.minor.patch), not a UUID.
+  # This is intentional per the contract registry design where contracts are identified
+  # by their name and version, enabling human-readable queries and deduplication.
+  - file_pattern: 'nodes/contract_registry_reducer/models/model_payload_.*\.py'
+    violation_pattern: "Field 'contract_id' should use UUID"
+    reason: >
+      contract_id is a derived natural key (node_name:major.minor.patch), not a UUID. This design enables human-readable queries, version-based deduplication, and matches the contract.yaml identification pattern used throughout ONEX.
+
+    documentation:
+      - CLAUDE.md (Intent Model Architecture - Contract Identity)
+    ticket: OMN-1653
+  # node_name is the contract's semantic name, not an entity reference requiring ID + display_name.
+  - file_pattern: 'nodes/contract_registry_reducer/models/model_payload_.*\.py'
+    violation_pattern: "Field 'node_name' might reference an entity"
+    reason: >
+      node_name is the contract's semantic identifier from contract.yaml, not a reference to a separate entity. Contracts are identified by name, making this a primary attribute not a foreign key.
+
+    documentation:
+      - CLAUDE.md (Contract-Driven - node_name conventions)
+    ticket: OMN-1653
+# Architecture validator exemptions
+# These handle one-model-per-file violations for domain-grouped protocols
+architecture_exemptions:
+  # ==========================================================================
+  # Emit Daemon Config Input Model Exemption (OMN-1610)
+  # ==========================================================================
+  # config.py contains ModelEmitDaemonConfigInput (intermediate input model)
+  # and ModelEmitDaemonConfig (final validated config). The input model is
+  # tightly coupled and only used internally by with_env_overrides() factory.
+  - file_pattern: 'emit_daemon/config\.py'
+    violation_pattern: '\d+ models in one file'
+    reason: >
+      ModelEmitDaemonConfigInput is an intermediate input model used only by ModelEmitDaemonConfig.with_env_overrides() factory method. It provides early validation for environment variable parsing and is tightly coupled with the main config model. Separating would add complexity without benefit.
+
+    documentation:
+      - CLAUDE.md (Protocol File Naming - domain-grouping convention)
+    ticket: OMN-1610
+  # ==========================================================================
+  # Emit Daemon Protocol Models Exemption (OMN-1610)
+  # ==========================================================================
+  # Request and response models form discriminated unions that are always used
+  # together. Separating into individual files would break the cohesive API.
+  - file_pattern: 'emit_daemon/model_daemon_request\.py'
+    violation_pattern: '\d+ models in one file'
+    reason: >
+      ModelDaemonPingRequest and ModelDaemonEmitRequest form a discriminated union (ModelDaemonRequest) for the daemon protocol. These request types are always parsed together via parse_daemon_request(). Per CLAUDE.md domain-grouping convention for protocol messages.
+
+    documentation:
+      - CLAUDE.md (Protocol File Naming - domain-grouping convention)
+    ticket: OMN-1610
+  - file_pattern: 'emit_daemon/model_daemon_response\.py'
+    violation_pattern: '\d+ models in one file'
+    reason: >
+      ModelDaemonPingResponse, ModelDaemonQueuedResponse, and ModelDaemonErrorResponse form a discriminated union (ModelDaemonResponse) for the daemon protocol. These response types are always parsed together via parse_daemon_response(). Per CLAUDE.md domain-grouping convention for protocol messages.
+
+    documentation:
+      - CLAUDE.md (Protocol File Naming - domain-grouping convention)
+    ticket: OMN-1610
+  # ==========================================================================
+  # Contract Linter Models Exemption (PR #57)
+  # ==========================================================================
+  # linter_contract.py contains domain-grouped validation models and enums
+  # that are cohesive and always used together. These define the complete
+  # interface for contract linting results.
+  - file_pattern: 'validation/linter_contract\.py'
+    violation_pattern: '\d+ models in one file'
+    reason: >
+      Domain-grouped validation result models for contract linting. ModelContractViolation and ModelContractLintResult define the complete interface for contract validation results. Per CLAUDE.md domain-grouping convention for cohesive models that are always used together.
+
+    documentation:
+      - CLAUDE.md (Protocol File Naming - domain-grouping convention)
+      - docs/validation/validator_reference.md
+    ticket: PR-57
+  - file_pattern: 'validation/linter_contract\.py'
+    violation_pattern: 'Mixed types in one file'
+    reason: >
+      Contract linter module contains cohesive types (enum + models) for validation results. EnumContractViolationSeverity is tightly coupled with ModelContractViolation and ModelContractLintResult.
+
+    documentation:
+      - CLAUDE.md (Protocol File Naming)
+      - docs/validation/validator_reference.md
+    ticket: PR-57
+  # ==========================================================================
+  # Domain-Grouped Protocol Exemptions (CLAUDE.md Convention)
+  # ==========================================================================
+  # Per CLAUDE.md "Protocol File Naming" section:
+  # "Domain-grouped protocols: Use protocols.py when multiple cohesive protocols
+  # belong to a specific domain or node module"
+  - file_pattern: 'nodes/node_registration_orchestrator/protocols\.py'
+    violation_pattern: '\d+ protocols in one file'
+    reason: >
+      Domain-grouped protocols for registration orchestrator workflow. ProtocolReducer and ProtocolEffect define the complete interface for the reducer-effect pattern in node registration. Per CLAUDE.md convention.
+
+      Architectural documentation included in module: - Concurrency safety requirements (lines 13-24): Implementations MUST be coroutine-safe - Error sanitization guidelines (lines 26-52): NEVER include credentials in errors - Protocol contracts with examples in docstrings
+
+      Full architectural documentation: - Node architecture: docs/architecture/REGISTRATION_ORCHESTRATOR_ARCHITECTURE.md - Protocol design: docs/architecture/NODE_REGISTRATION_ORCHESTRATOR_PROTOCOLS.md - Node README: src/omnibase_infra/nodes/node_registration_orchestrator/README.md
+
+    documentation:
+      - docs/architecture/REGISTRATION_ORCHESTRATOR_ARCHITECTURE.md
+      - docs/architecture/NODE_REGISTRATION_ORCHESTRATOR_PROTOCOLS.md
+    ticket: OMN-888
+  # ==========================================================================
+  # ServiceTimeoutEmitter Models Exemption (OMN-932)
+  # ==========================================================================
+  # service_timeout_emitter.py contains domain-grouped models for timeout emission:
+  # - ModelTimeoutEmissionResult: Result of timeout emission processing
+  # - ModelTimeoutEmissionConfig: Configuration for the emitter
+  # These are tightly coupled and always used together.
+  - file_pattern: 'services/service_timeout_emitter\.py'
+    violation_pattern: '\d+ models in one file'
+    reason: >
+      Domain-grouped models for timeout emission. ModelTimeoutEmissionResult and ModelTimeoutEmissionConfig define the complete interface for the ServiceTimeoutEmitter. Per CLAUDE.md domain-grouping convention for cohesive models that are always used together.
+
+    documentation:
+      - CLAUDE.md (Protocol File Naming - domain-grouping convention)
+      - docs/patterns/timeout_scanner_emitter.md
+    ticket: OMN-932
+# These handle complex union type violations
+union_exemptions:
+  # ==========================================================================
+  # ModelNodeCapabilities Config Field Exemption
+  # ==========================================================================
+  # Design Doc: CLAUDE.md "Type Annotation Conventions" section - Union patterns
+  - file_pattern: 'model_node_capabilities\.py'
+    violation_pattern: 'Union with 4\+ primitive types.*bool.*float.*int.*str'
+    reason: >
+      The config field uses dict[str, int | str | bool | float] for nested configuration values. This is a standard JSON-like config pattern where values can be any primitive type. Creating a ModelConfigValue wrapper would add unnecessary complexity without real benefit for this infrastructure domain.
+
+    documentation:
+      - CLAUDE.md (Type Annotation Conventions - Union patterns)
+      - Standard JSON config pattern (RFC 8259)
+    ticket: null