What is PatchPatrol

PatchPatrol by aistack reviews bounded GitLab merge-request context with a model endpoint you configure. The CI job writes JSON, Markdown, and HTML reports for the team to inspect. These reports support human review; PatchPatrol does not replace the reviewer or decide whether code can merge.

The GitLab component is the primary public workflow. Start in artifact-only mode and read the Run Reports before enabling optional merge-request feedback. PatchPatrol also supports GitHub Actions and local diff review.

What bounded review means

Each PatchPatrol review follows a defined contract:

1. It selects the requested diff and applies configured scope limits before a model call.
2. It applies pattern-based redaction to extracted diff chunks.
3. If you configure an endpoint allowlist, the Trust Gate checks the model endpoint.
4. It sends the bounded review context to the configured model endpoint.
5. It validates provider output before accepting findings.
6. It writes artifacts that show the result and its operational evidence.

A bounded review can still miss risks, and it does not replace human judgment. "Bounded" means the run records its inputs, limits, trust decisions, and outputs. The architecture guide explains the runtime flow. Security & Privacy documents the provider, credential, code-context, and retention boundaries.

What the review produces

The job writes human-readable Markdown and HTML reports as ai-review.md and ai-review.html. It also writes ai-review.json as the canonical machine-readable Run Report.

After they are comfortable with the reports, teams can enable a persistent GitLab Review Summary and separate Inline Findings for eligible changed lines. Those delivery surfaces complement the Run Reports. They do not turn PatchPatrol into a merge approval or quality gate.

See First review output for the artifact contract and Feedback modes for the optional GitLab delivery behavior.

Who PatchPatrol is for

PatchPatrol fits teams that:

• Review GitLab merge requests in CI and want an additional, repeatable review signal.
• Need to see the review scope and provider boundary for each run.
• Want reviewers to inspect artifacts before enabling merge-request feedback.
• Can operate a customer-controlled runtime and choose a customer-controlled model endpoint when its data boundary requires one.

PatchPatrol supports Ollama and OpenAI-compatible endpoints. A configured endpoint may run in infrastructure you control or on a remote service. The Security & Privacy guide explains how that choice changes data handling.

When PatchPatrol may not fit

PatchPatrol is probably not a fit if you need:

• An autonomous replacement for human review or a guaranteed defect detector.
• Public self-service image access, licensing, or an immediately started trial.
• An unbounded repository-wide assessment instead of change-scoped review.
• Identical setup instructions for every Git host.

The documented setup focuses on GitLab. GitHub Actions and local review remain supported, but they are not covered by this setup guide.

Next steps

• Architecture traces context selection, provider calls, validation, and artifact writing.
• Security & Privacy explains runtime and provider responsibilities.
• The Admin Quickstart lists access prerequisites and sets up the first GitLab review.
• The Developer Quickstart shows developers how to run and inspect a review after the admin handoff.
• First review output documents the artifact and review-surface contract.

Visit the PatchPatrol product website

for the short product overview.

Discuss a private GitLab review pilot

if you want to evaluate PatchPatrol in your environment.