cognitive-load-firewall

An adaptive accessibility system that reshapes digital content around a user’s current cognitive tolerance, reducing overload while preserving critical information.

Comment

Inspiration

Cognitive Load Firewall was inspired by a simple question: why should a person experiencing cognitive fatigue, sensory overload, or concussion recovery be forced to adapt to a rigid digital interface?

Most digital platforms present the same amount of text, motion, visual density, and task complexity to every user. For someone dealing with temporary cognitive overload, even reading an assignment or following multi-step instructions can become exhausting.

We wanted to reverse that relationship.

Instead of asking the person to adapt to the interface, the interface adapts to the person.

What it does

Cognitive Load Firewall is an adaptive accessibility system that analyzes digital content and reshapes how it is presented based on the user's current cognitive preferences.

The user begins with a lightweight tolerance profile covering areas such as:

  • Reading load
  • Attention demand
  • Memory demand
  • Visual density
  • Motion
  • Information density

These values are personalization preferences, not medical measurements.

The system then creates a Load Spectrum that compares the estimated load of the content with the user's current preferences and identifies where the largest mismatch occurs.

Based on that mismatch, the interface can:

  • Break dense text into smaller chunks
  • Simplify presentation
  • Guide the user step by step
  • Reduce visual complexity
  • Reduce unnecessary motion
  • Preserve context for memory support
  • Create calmer reading sessions

The user can always switch between:

  • Original
  • Adapted
  • Difference

so they can clearly see what changed.

Safety and Responsible AI

One of the biggest priorities was making the system useful without allowing it to make unsafe medical claims.

Cognitive Load Firewall does not:

  • Diagnose concussion
  • Estimate recovery
  • Recommend medication
  • Clear a user for sports
  • Clear a user for driving
  • Replace professional medical advice

A deterministic safety gate runs before normal adaptation. If the system detects a high-risk health statement, normal productivity adaptation stops and the user is encouraged to seek appropriate medical help.

Every adaptation also produces an AI Decision Receipt that explains:

  • Which rules were triggered
  • Why the interface changed
  • Which profile information was used
  • Whether safety checks passed
  • Whether important information was preserved

This makes the system more transparent and easier to audit.

How we built it

The project is built with:

  • Next.js
  • React
  • TypeScript
  • Zod
  • Prisma
  • PostgreSQL support
  • Vitest
  • Render
  • Render Workflows

The adaptation process is divided into multiple stages.

A real request triggers our Render workflow:

adaptContentWorkflow

which coordinates separate tasks for:

  1. validateAndSafety
  2. analyzeCognitiveLoad
  3. transformAndVerify

This means the adaptation pipeline is not just hosted on Render. Render Workflows is part of the core execution path of the project.

The system analyzes characteristics such as reading density, sentence complexity, sustained attention demand, memory load, visual complexity, and motion-related load.

It then calculates a mismatch between content load and the user's current preferences.

Conceptually:

$$ M_i = \max(0, C_i - T_i) $$

where:

  • (C_i) is the estimated content load for a dimension
  • (T_i) is the user's current tolerance preference
  • (M_i) is the resulting mismatch

The mismatch is used only for interface adaptation and is not a medical or neurological score.

Fidelity verification

Simplifying information creates an important engineering risk: changing something critical by accident.

To reduce that risk, we built a fidelity verification layer that checks for information such as:

  • Numbers
  • Dates
  • Warnings
  • Requirements
  • Deadlines
  • Safety instructions
  • Important directives

The system keeps the original content available at all times and allows the user to inspect what was changed.

Accessibility

Accessibility is part of the product architecture, not an afterthought.

The interface includes:

  • Keyboard navigation
  • Visible focus states
  • Reduced-motion support
  • High-contrast surfaces
  • Text scaling
  • Read-aloud support
  • Calm Mode
  • No color-only status indicators
  • Responsive layouts

We also created an interactive Accessibility Lab where users can preview how reading scale, contrast, motion restraint, and focus emphasis affect the interface.

Accommodation Card

Another feature we built is the Accommodation Card.

Instead of forcing a person to reveal a diagnosis or full health history, the card can communicate only the functional support they need, such as:

  • Shorter reading blocks
  • Reduced visual motion
  • Extra processing time
  • Lower-distraction environments

This keeps the focus on accessibility needs while protecting unnecessary medical information.

Challenges we faced

The biggest challenge was balancing simplification with fidelity and safety.

Making content easier is useful only if important meaning is preserved.

We had to design the system so that:

  • Critical information remains available
  • Adaptation decisions are explainable
  • Safety rules run before normal transformation
  • The system never pretends to make clinical decisions
  • The interface stays calm without becoming oversimplified

Another challenge was building a real distributed execution pipeline using Render Workflows and connecting the live application to it reliably.

What we learned

We learned that accessibility is not only about larger text, color contrast, or screen readers.

Cognitive accessibility can also mean changing:

  • Information density
  • Task sequencing
  • Motion
  • Visual complexity
  • Memory demand
  • The number of simultaneous decisions shown to the user

We also learned that responsible AI systems should make their reasoning visible and preserve a clear boundary between interface assistance and medical decision-making.

What we are proud of

We are especially proud that Cognitive Load Firewall is not another generic chatbot or symptom tracker.

The project explores a different idea:

the user is not the interface problem. The interface is the adaptation target.

We also successfully implemented a real multi-stage Render Workflow with separate safety, analysis, and transformation tasks running as part of the live system.

What's next

Future versions could expand Cognitive Load Firewall into a broader adaptive environment layer.

Possible next steps include:

  • Browser-level webpage adaptation
  • PDF and document ingestion
  • More advanced evidence-aware retrieval
  • User-controlled personalization history
  • Clinician-provided constraints
  • School and workplace accessibility integrations
  • Optional device and environmental signals
  • Additional languages

The long-term goal is simple:

The user should not have to fight the interface. The interface should know when to get out of the way.

Built With

Share this project:

Updates

Submission history