[Overview](/docs)[Installation](/docs/installation)[Architecture](/docs/architecture)[Integrations](/docs/integrations)[First review](/docs/review)[Operations](/docs/operations)[Acceptance](/docs/acceptance)

# When to start a company pilot.

A checklist of outcomes, not just available settings.

## Current state

Technical evaluation. A bounded real MR3 is preserved. Full acceptance of the current build is incomplete. The website design and green component tests do not change this status.

## Launch gates

| Area | Required outcome  |
| --- | --- |

| Installation | Clean Linux amd64 host, current package, all stages, useful operation and version correspondence.  |

| SSO / tenants | Two tenants, real roles, cross-tenant denial, logout and restart.  |

| ContextForge | SSO, enrollment, consent, useful protected read, revocation and restart. initialize/list alone is insufficient.  |

| GitLab / model / CI | A defective MR, assignment/mention, finding, fix, new SHA, re-review, current CI and authorized approve without duplicates.  |

| Recovery | Ambiguous API outcomes, retries and restarts do not duplicate publication or CI. Backup restoration is tested.  |

| Load | Five real overlapping reviews, queue, memory, cost, provider limits and p95 against agreed thresholds.  |

## Run a bounded pilot

- Start with one repository and an accountable technical lead. Agree on criteria and a time window first.

- Use historical MRs with known defects. Track useful findings, false positives and misses separately.

- Evaluate drafts first. Enable publication and approve separately after permission and freshness checks.

- Record cost, load and the team’s decision. Expand scope only after acceptance.