PRISM (Proactive Remediation & Intelligent Software Monitor)

Role: Solo, end-to-end. architecture, analysis pipeline, compression engine, CLI, reporting
Tech Stack: Python 3.8+, Playwright, AsyncIO, Pydantic, OpenAI/Anthropic/Ollama, Pytest
Repository: Private. Demo available on request

Overview

PRISM is a modular, AI-powered web quality analysis platform. The name is literal: just as a glass prism refracts white light into a visible spectrum, PRISM takes the raw state of a web app and splits it through specialized Spectral Modules, each analyzing a different “wavelength” of software quality.

Most web analysis tools do one thing. Lighthouse checks performance. axe-core checks accessibility. Visual regression tools compare screenshots. PRISM runs a unified pipeline where responsive design, accessibility, performance, security, SEO, and localization all go through the same capture-compress-analyze architecture, and each module produces copy-paste-ready artifacts (CSS fixes, HTML snippets, config files) rather than vague recommendations.

The system captures pages across multiple device viewports, runs a compression pipeline that cuts token costs by 70-90%, sends compressed data to specialist LLM agents that analyze each viewport in parallel, and then synthesizes findings across viewports into actionable output.

System Architecture

PRISM uses a capture-compress-analyze pipeline: Playwright captures raw page state, a compression engine strips it down to what matters, and parallel LLM agents analyze each viewport before a synthesis step resolves cross-viewport conflicts.

graph TD
    subgraph "Capture Layer"
    A[Target URL] --> B[Playwright Browser Manager]
    B --> C[Mobile Capture]
    B --> D[Tablet Capture]
    B --> E[Desktop Capture]
    end

    subgraph "Compression Layer"
    C --> F{Smart Compressor}
    D --> F
    E --> F
    F -->|PII Scrubbing| G[Violet Hook]
    F -->|DOM Skeleton| H[HTML Compression]
    F -->|Style Summary| I[CSS Compression]
    F -->|Screenshot Chunks| J[Image Optimization]
    end

    subgraph "Analysis Pipeline"
    H --> K[ViewportAgent - Mobile]
    H --> L[ViewportAgent - Tablet]
    H --> M[ViewportAgent - Desktop]
    K --> N[InterpreterAgent]
    L --> N
    M --> N
    N --> O[Unified Report + CSS Artifacts]
    end

    K -.-> P[OpenAI GPT]
    K -.-> Q[Anthropic Claude]
    K -.-> S[Local via Ollama]

Components

• Smart Compressor: the economic engine of the whole thing. Extracts DOM skeletons via BeautifulSoup, counts class usage, identifies layout patterns (grid/flex), summarizes form elements, compresses CSS via cssutils. Tall screenshots get split into overlapping viewport-height chunks for better LLM vision analysis. Reduces LLM token volume by 70-90%.
• ViewportAgent: takes compressed data for a single viewport, builds structured prompts, sends to the configured LLM with screenshot images, and validates responses against a Pydantic ViewportReport schema. Runs in parallel via asyncio.gather.
• InterpreterAgent: synthesizes all viewport reports into unified recommendations, resolving conflicts (a hamburger menu is correct on mobile but a bug on desktop).
• LLM Provider Layer: abstract LLMProvider base class with concrete implementations for OpenAI, Anthropic, and local Ollama. Supports vision, streaming, retry logic, prompt caching, and model snapshot pinning for production reproducibility. Tiered pricing configs (best/balanced/cheapest).
• Device Classification: loads from a curated device_classes.json with 2024-2025 market data. Maps viewport widths to device classes so responsive logic can be validated in context.

The Spectral Module System

Each analysis dimension maps to a color in the visible light spectrum. This isn’t branding, it’s the architecture. Test directories, documentation, and the plugin system are all organized by color.

Every module follows a “Pipelines, Not Engines” philosophy: wrap proven tools (Pillow for pixel diffs, BeautifulSoup for DOM parsing, axe-core for accessibility, regex/presidio for PII detection) rather than rebuilding from scratch. The LLM’s job is reasoning about why things broke and synthesizing findings, not detection.

Engineering Details

1. Smart Compression (The Economic Enabler)

Sending full HTML, CSS, and high-res screenshots to LLM APIs is prohibitively expensive. Without optimization the whole concept is a non-starter. So I built a dedicated compression pipeline that cuts token volume by 70-90% while preserving the signal LLMs actually need.

• HTML reduces to a structural DOM skeleton: tag hierarchy, class usage counts, ID extraction, form element summaries, layout pattern detection (grid/flex).
• CSS is compressed via cssutils, stripping redundancy while preserving responsive breakpoints.
• Screenshots get chunked intelligently into overlapping viewport-height segments. LLMs analyze images better at native resolution than as a massively scaled-down full-page capture.
• Token usage is calculated before sending requests so budgets don’t get blown.

This compression is what makes every other module economically viable. Without it, PRISM is an interesting prototype. With it, it’s a tool you can actually run on every deploy.

2. Multi-Agent Viewport Analysis

A single LLM call analyzing all viewports at once produces vague, unfocused output. But separate analyses contradict each other. So I built a two-stage agent pipeline: parallel specialist analysis followed by cross-viewport synthesis.

• ViewportAgent instances run in parallel via asyncio.gather, each analyzing a single viewport with device-specific context.
• Each agent’s response is validated against a Pydantic ViewportReport schema, structured, parseable, no loose JSON drift.
• The InterpreterAgent receives all viewport reports and resolves conflicts: is a missing sidebar a bug (desktop) or correct behavior (mobile)?
• Final output includes unified CSS recommendations, an HTML report with collapsible viewport sections and screenshot thumbnails, and a markdown master plan.

3. Privacy-First PII Scrubbing

Web pages contain sensitive data, emails, phone numbers, API keys, SSNs. Sending raw page content to external LLMs is a real privacy risk. So the Violet module’s PII scrubber runs deterministically before any data reaches an LLM.

• Regex-based detection for emails, SSNs, API keys, and phone numbers.
• Scrubbing happens in the compression layer, upstream of the analysis pipeline, so raw HTML text never reaches a provider API unscrubbed.
• Not optional, not configurable. Runs by default on every analysis.
• One honest caveat: full-page screenshots go to vision LLMs unredacted, so PII that’s visibly rendered on the page can still reach the provider as pixels. Screenshot redaction is on the roadmap.

4. Provider Abstraction with Production Pinning

Different LLM providers have different SDKs, payload formats, vision capabilities, and pricing. The system has to work with any provider without vendor lock-in. Abstract LLMProvider base class with concrete implementations that normalize inputs and outputs.

class LLMProvider(ABC):
    @abstractmethod
    async def chat(self, messages: list[dict], system: str = None) -> str:
        pass

    @abstractmethod
    async def analyze_image(self, image_b64: str, prompt: str) -> dict:
        pass

# Swap providers with a config change
class OpenAIProvider(LLMProvider): ...
class ClaudeProvider(LLMProvider): ...
class OllamaProvider(LLMProvider): ...
# GeminiProvider is the planned next implementation of this extension point
# (pricing tiers are already configured, the provider itself isn't built yet)

• Tiered pricing configs (best/balanced/cheapest) let users choose their cost-quality tradeoff.
• Model snapshot pinning keeps production analyses reproducible across runs.

Current State

PRISM is an active, evolving project. The core pipeline and Blue (Viewport/Design) module are production-complete. Other modules are at various stages:

• Built: White (Core), Blue (Viewport), full capture-compress-analyze pipeline with multi-viewport synthesis and HTML reporting
• Partially Built: Red (Regression), pixel diffing via Pillow implemented; Violet (Fortress), PII scrubbing implemented in compression layer
• Planned: Green (Access), Orange (Discovery), Yellow (Velocity), Indigo (Global)
• Test Coverage: 303+ tests across core, agents, LLM providers, integration, and the CLI (PII scrubbing covered; the pixel-diff utility isn’t yet)

Tech Stack

• Core: Python 3.8+, AsyncIO
• Automation: Microsoft Playwright
• AI/LLM: OpenAI, Anthropic Claude, Ollama (local inference), provider-agnostic with tiered pricing (Gemini planned; pricing tiers configured, provider not yet implemented)
• Compression: BeautifulSoup, cssutils, Pillow
• Validation: Pydantic (config and response schemas)
• Testing: Pytest, Pytest-Asyncio (303+ tests)
• DevOps: GitHub Actions