Context, Memory & Preferences

Pixee is not a generic code scanner that applies one-size-fits-all patches. It reads your repository, learns your team's conventions and frameworks, and improves from the feedback your team provides when it reviews and merges fixes. This page explains how that context is gathered, stored, and used.

Codebase Context

Before Pixee generates a fix, it analyzes the repository for the patterns, frameworks, and security controls already in use. This context shapes every fix Pixee produces.

What Pixee reads:

• Existing patterns and conventions — naming conventions, preferred utility classes, error handling patterns, code style. If your team wraps SQL calls in a DatabaseHelper, Pixee generates fixes that use DatabaseHelper, not a raw JDBC pattern.
• Frameworks and libraries in use — Spring Boot, Django, Express, ASP.NET Core, and others each have idiomatic secure coding patterns. Pixee's framework-aware fixes match what your team already uses.
• Dependencies — the libraries and versions in your manifest files inform what fix patterns are available and safe. If your project already includes an input validation library, Pixee prefers it over introducing a new dependency.
• Existing security controls — middleware, sanitization utilities, authentication layers, and framework-provided security features. A finding protected by framework-level controls is classified differently from the same pattern without protection.

This analysis is performed at the repository level for each analysis run. Code is not stored after the analysis completes. See Security Architecture for data handling details.

PIXEE.yaml

Team-level preferences and repository configuration are specified in a PIXEE.yaml file in the repository root. PIXEE.yaml is the primary mechanism for telling Pixee how to behave in your repository.

Common configuration includes:

• Scoping fix generation to specific severity levels, vulnerability types, or repository paths
• Excluding files, directories, or patterns from analysis
• Setting branch targeting preferences
• Configuring PR batching and delivery behavior

PIXEE.yaml is optional — Pixee works with sensible defaults without it. For the full schema and all available options, see PIXEE.yaml Reference.

Learning from Feedback

Pixee improves from the signals your team sends when it interacts with Pixee-generated PRs. These signals are the primary mechanism by which Pixee adapts to your team's preferences and risk tolerance over time.

Signals Pixee collects:

Signal	What It Means
PR merged (as-is)	Fix was correct and matched team conventions — positive signal for this fix pattern
PR merged (with modifications)	Fix was directionally correct but needed adjustment — Pixee notes the delta
PR closed / declined	Fix was not accepted — negative signal for this finding type or fix approach
Triage override	Team disagreed with Pixee's classification — updates classification logic for similar findings

Observing improvement: Teams that have been using Pixee for several weeks typically see improved triage outcomes and higher merge rates as the system calibrates to their codebase and review preferences.

Triage Overrides

When Pixee classifies a finding as a true positive but your team disagrees — or vice versa — you can override the triage verdict. Overrides are the strongest feedback signal available.

How to override: Overrides can be submitted in three ways: by providing feedback directly on an individual triage result, via natural language preferences in PIXEE.yaml, or through Organization Preferences in the UI.

What happens when you override:

• The specific finding's verdict is updated immediately.
• The override is recorded with the rationale (if provided).
• Future findings matching the same pattern in the same codebase context receive adjusted classification.

Influence on future classifications: Triage overrides influence how Pixee classifies similar findings going forward. The more specific the context (same rule ID, same file pattern, same framework), the more targeted the adjustment.

Enterprise Context

For organizations with specific policies — approved libraries, banned patterns, internal framework conventions — surfacing that context to Pixee allows fix generation to align with enterprise standards rather than generic open-source patterns.

Mechanisms for providing enterprise context:

• PIXEE.yaml — per-repository configuration for fix scope and behavior preferences.
• Organization Preferences — org-level configuration in the UI for specifying approved libraries, banned patterns, and internal framework conventions that apply across all repositories.
• Codebase reading — Pixee automatically detects internal libraries and frameworks by analyzing imports, dependency manifests, and usage patterns. If your organization uses an internal HTTP client wrapper, Pixee detects it and uses it in fixes.

For organizations managing hundreds of repositories, the Phased Rollout Guide covers organization-wide deployment strategy that accounts for repository-level variation in conventions and risk tolerance.