View Categories

How the CSS Rule Engine Works

2 min read

When you click Diagnose, Lens doesn’t send your CSS data to a language model and ask it to describe what’s wrong. The diagnosis comes from a rule engine: a classification system that runs locally, reads the structured CSS data, and determines what’s happening based on patterns it knows how to identify.

This matters because it means the diagnosis is deterministic. The same CSS state produces the same diagnosis every time. There’s no variability, no hallucination, no confidence problem from a model that’s guessing based on text patterns. The engine either finds a match or it doesn’t, and if it doesn’t, it says so directly instead of producing something plausible-sounding but wrong.

What the engine looks at #

After you select a property and type your target value, the engine focuses on that property. It reads the specificity ladder for that property: every rule that tried to set it on the element you clicked, ranked by priority. For each rule, it knows the selector, the value, the origin, whether it uses !important, whether it’s inside a @media query, whether it’s in a CSS @layer, and where in the stylesheet load order it appears.

From that data, the engine determines:

  • Which rule is currently winning and why
  • Which rules tried and lost, and the specific reason each one lost
  • Whether a safe override can be generated, and what it would look like
  • Which triage route applies

What happens when the engine can’t resolve it #

Some situations fall outside what the engine can classify with confidence: ambiguous cascade states, CSS-in-JS with runtime class names, or capture data that’s incomplete because the element was in an unusual state. In those cases, the engine routes to capture-insufficient rather than producing a guess. The capture file still contains everything a developer needs to investigate.

No server call after Diagnose #

The session logging step and the engine run in sequence: when you click Diagnose, Lens calls Loupely’s server to log the session, then the engine runs locally in the popup. There’s no second server call for the analysis. What you see in Fight View is produced in your browser from the capture data already on your machine.