Cognitive Load Rule Engine
Component Detail
Description
Enforces all cognitive accessibility constraints at the service layer, independent of UI rendering. Validates wizard step counts, choice counts per screen, and explicit user confirmation requirements. Used by screen generators and the wizard orchestrator to catch violations early.
cognitive-load-rule-engine
Summaries
The Cognitive Load Rule Engine protects the organization from shipping experiences that overwhelm users with complex cognitive needs — a growing regulatory and reputational concern as accessibility requirements tighten globally. By enforcing validated limits on wizard step counts and per-screen choice counts at the service layer, this component prevents costly post-launch redesigns triggered by usability failures or accessibility audits. Catching violations early in the development cycle is significantly cheaper than remediating them after user testing or regulatory review. For products targeting users with cognitive disabilities, educational contexts, or older demographics, this component is a direct contributor to user retention, satisfaction scores, and defensible accessibility compliance.
This medium-complexity service component operates independently of any UI framework, which simplifies testing but requires close coordination with the screen design and wizard orchestration teams to agree on constraint values — maximum five wizard steps and maximum three primary choices per screen — before implementation begins. These thresholds must be reviewed with product owners and accessibility consultants as part of requirements sign-off, since changing them post-delivery triggers re-validation of all dependent wizard configurations. There are no listed external dependencies, reducing integration risk. The main scheduling concern is ensuring this component is delivered and approved before any wizard or screen generator components begin development, as those components depend on it for early violation detection.
The Cognitive Load Rule Engine is a stateless service-layer validator with no external dependencies, making it straightforward to unit test in isolation. Core interfaces: `validateWizardConfig(config): ValidationResult`, `validateScreenChoices(choices): ValidationResult`, `assertExplicitAdvance(transitionConfig): boolean`, and `getViolations(config): Violation[]`. It enforces three primary invariants: wizard step count ≤ 5, primary choice count per screen ≤ 3, and all wizard transitions require explicit user action with no auto-advance. Violations are returned as structured `Violation` objects, enabling callers — screen generators and the wizard orchestrator — to surface actionable feedback rather than generic errors.
Integration should occur at configuration-parse time rather than render time, surfacing violations during development instead of at runtime in production.
Responsibilities
- Validate wizard step count does not exceed 5
- Assert maximum of three primary choices per screen definition
- Block auto-advance: confirm all wizard transitions require explicit user action
- Return structured validation results with violation details
Interfaces
validateWizardConfig(config): ValidationResult
validateScreenChoices(choices): ValidationResult
assertExplicitAdvance(transitionConfig): boolean
getViolations(config): Violation[]
Relationships
Dependents (1)
Components that depend on this component