? The guide
How Trevo works, with something real to click.
Seven short chapters for the person setting Trevo up and the engineer reviewing it. Each chapter links to the exact screen it explains in a seeded demo workspace, so you can check the product while you read.
Trevo in three minutes
The whole arc — observe, propose, pull request, measure, ship — on one page.
3 min · demo: open the workspace02Connecting GitHub and choosing repositories
The account is the GitHub sign-in. The permission model is the first thing an engineer checks.
4 min · demo: see the connected repo03Installing the SDK and verifying events
Client and server, one identity, and the green tick that means it is live.
5 min · demo: see the events arriving04How proposals get written
The repo scan, the evidence chain, and why a proposal can exist before any traffic does.
5 min · demo: read a proposal, then approve it05Approving, reviewing the PR, and what Trevo never touches
The branch policy, the experiment gate, the temporary clone.
4 min · demo: read a pr the bot wrote06Reading results and shipping a winner
The verdict, the three tiles, how to read “Too soon to tell”, and the cleanup PR.
5 min · demo: read a called, shipped result07Teams: inviting people, roles, and the audit trail
Who can approve, who can merge, and how every decision is recorded.
3 min · demo: see the decisions on record• Security & your data
What Trevo sees, keeps, and hands back.
Trevo has the access a contractor on their first day would get — read on your default branch, write only on trevo/* branches, and never a merge without you. Here is exactly what that means for your code and your data.
Do you own or keep a copy of our code?
No. Connecting a repository does not transfer ownership of your code to Trevo. Trevo does not keep a source-code clone: scan and pull-request jobs use a temporary workspace that is removed when the job finishes. Trevo keeps a derived structural snapshot — routes, components, server-side logic, file paths, and short descriptions — inside your workspace so it can ground proposals and changes. Disconnecting removes that snapshot from the active product.
What exactly can Trevo see?
The GitHub App can read the repositories you select and create branches and pull requests in them. Trevo reads the configured default branch and its product workflow writes changes only to trevo/* branches; it does not merge or deploy them. Your CI, CODEOWNERS, and branch protection still decide what can reach the default branch. You can revoke the GitHub App at any time.
Do you train an AI model on our code or our metrics?
No. Repository content and experiment metrics are not used to train models. Trevo uses model providers to process the context needed for a scan, proposal, or requested code change, and we can share the current provider list on request.
How do experiments ship — could Trevo break production?
Trevo never deploys and never merges. It opens a pull request; your engineers review and merge it exactly like any other PR, through your existing CI and checks. Variant assignment then runs inside your own code from a synced config snapshot — there is no blocking third-party script in your critical path. Starting an experiment only flips traffic on code you already merged, and if you do not like a variant you simply close the PR and nothing changes.
What happens to our data if we disconnect?
Disconnecting stops Trevo from using that repository connection and removes its structural snapshots from the active workspace. Uninstalling or revoking the GitHub App removes the GitHub-granted access. Deleting a workspace revokes its SDK and API keys, removes its active workspace data, and deletes stored payload objects; append-only audit records remain as the security history.