Enterprise readiness

Developer tests

• Don't Waste My Time: findings must be concrete, structural, and code-specific.
• Context Boundary: findings must be grounded in the repository, not guessed from a short prompt alone.
• Workflow Disruption: the review loop must stay inside the existing git workflow, terminal commands, and repo-native evals.
• If the system cannot point at a real file, route, config key, graph edge, or CI artifact, it should return no finding instead of generic advice.

Data gateway

• Repository content is consumed by background workers and reduced into structured findings, clusters, issue candidates, and audit snapshots.
• The reviewer console persists operational artifacts, not a copy of the repository tree.
• Provider tokens remain server-side and are scoped to the integration needed for the task.

AI privacy

• Prompts are shaped by a workflow contract that rejects generic output and refuses weak evidence.
• Consensus validation drops low-confidence worker noise before it reaches reviewer queues.
• Output scrubbing removes sensitive strings from generated text before persistence or publish.

Tenant isolation

• Organization-scoped queries, Supabase RLS, and server-side session context separate workspace data.
• Webhook handlers validate inbound signatures before they can enqueue work.
• The worker boundary is designed so one tenant cannot read another tenant’s audit state.

Provider support matrix

• GitLab: supported for connect, ingest, publish, and reconciliation.
• GitHub: repository integration is roadmap and not a supported production login dependency.
• Bitbucket: roadmap.
• Azure DevOps: roadmap.
• Gitea: roadmap.

Operational controls

• Audit runs are logged with actor, organization, timestamps, and workflow state.
• Review gates prevent direct agent-to-provider publish.
• Dedicated stop and resume controls make background runs observable and reversible.

Compliance evidence

• Audit trails should capture who triggered the run, which workspace it used, and what was approved.
• The system is structured to support SOC 2 style evidence collection through immutable run records and reconciliation history.
• Exportable audit history and workspace settings make security review evidence easier to assemble.

FAQ / security defensibility

**What data is stored?** Operational artifacts such as audit runs, findings, issue candidates, and reconciliation records. The reviewer console is not a mirrored copy of the repository tree. **How does the system avoid noisy output?** Worker lanes are filtered through a consensus validator. Candidates that lack concrete repository evidence, fail the confidence threshold, or look generic are rejected before they reach the review queue. **How is prompt injection handled?** Prompt payloads are sanitized before they reach the LLM layer, and generated text is scrubbed before persistence or publish. **Which providers are production-supported today?** GitLab is supported for connect, ingest, publish, and reconciliation. GitHub, Bitbucket, Azure DevOps, and Gitea remain roadmap surfaces until they are shipped and documented. **Can teams run this in their own environment?** SaaS is the default. Private-cloud or BYOK deployment is treated as a separate delivery track and must be documented and validated on its own terms.

Deployment modes

• SaaS is the default operational mode.
• The web, API, orchestrator, database, and graph layers are separated so a private-cloud deployment can be reasoned about cleanly.
• Self-hosted or BYOK packaging is a separate delivery track and should be documented before any enterprise commitment.