Security & data flow
ReviewSensei is an open-source review engine you run in your own GitHub Actions environment or locally. This page explains what crosses each boundary, what may persist, and what the project does not guarantee about model quality or provider retention.
Alpha software. Capabilities, defaults, and distribution channels evolve. Treat public examples as illustrative unless they link to retained evaluation or live-run evidence.
What ReviewSensei validates
These are separate layers. A finding passing one layer is not proof of another.
| Layer | What it means | What it does not prove |
|---|---|---|
| JSON / schema validation | Provider output conforms to the versioned review-result contract. | That a reported defect exists in your code. |
| Diff / location validation | Inline comments target paths and lines present in the supplied diff. | That coverage is complete or that omitted files are safe. |
| Deterministic evidence checks | The evidence_policy on a result names the publication gate. legacy is the default and publishes single-pass comments unchanged. Under confirmed, only candidates whose evidence exists in the exact reviewed snapshot are publishable, and incomplete verification downgrades the result to partial. |
That every finding was independently verified. legacy is still the default, so a result without evidence_policy: "confirmed" ran no candidate verification — and a second model's agreement is never treated as proof. |
| Model evaluation | Live promotion records bind specific model/policy/distribution combinations to retained evaluation evidence. | Broad model superiority or absence of security issues. |
| Approval eligibility | Automatic approval or request-changes requires completeness, current head, resolved threads, and promotion gates where applicable. | That a clean approval means no bugs remain. |
Execution vs inference
Where review logic runs
ReviewSensei executes in your GitHub Actions runner, self-hosted runner, or local CLI environment. The open-source engine prepares bounded prompts, validates responses, and produces review artifacts.
Where model inference runs
Inference runs at the endpoint you configure. Local Ollama keeps payloads on your machine. Ollama Cloud and other remote endpoints receive the selected diff, metadata, and trusted context. A local CLI configured for a remote service still sends review payloads to that service.
GitHub App / Cloudflare broker
The optional setup App and token broker issue scoped GitHub capability tokens. The broker is not the review or inference service. It does not receive model credentials or full review payloads for inference.
What may persist
The core engine does not persist raw prompts or raw provider responses. Other data has its own retention location and controls:
| Data | Typical location | Notes |
|---|---|---|
| Validated review results | CLI --output, workflow artifacts, optional publication to GitHub |
Retention depends on your workflow artifact settings and repository policies. |
| Published PR comments / reviews | GitHub | Controlled by publication switches and GitHub permissions. |
| Approved learnings | Repository files on the trusted base branch | Maintainer-approved; versioned in Git. |
| Recovery / coverage artifacts | Workflow artifacts when enabled | Bounded operational metadata; not a substitute for source control. |
| Provider-side copies | Your configured model service | ReviewSensei does not guarantee provider retention, training, residency, or deletion. Read your provider's current terms. |
Canonical documentation
For implementation detail, credential handling, and workflow-specific egress policy, use the repository docs:
- Data handling
- GitHub App authentication
- Security policy & reporting
- Evaluation & promotion evidence
- Public contracts —
evidence_policyvalues and approval blocker identifiers - ADR 0039 — candidate verification before publication
- Ownership & licensing