What access does Hybrid need, and where does the code run?
Read access to your repository plus the ability to push a branch and open a pull request, through a GitHub App scoped to that repository. A short recipe in .hybrid/app.yaml for starting and signing in to the app, confirmed by your engineer. Test-mode keys for outside services and a seed of test data.
Every run uses test data and test secrets in an isolated environment that is thrown away when the run ends. Hybrid never gets production data, production credentials, hosting credentials or deploy rights. We sign a mutual NDA before anyone looks at anything.
Which models see our source, and what do they decide?
A coding agent reads the code in the sandbox to write the change, and a model writes the plain-English summary on the card. Both run against a model provider’s API, so your source is handled under that provider’s terms; we name the provider and its terms before you connect anything.
Models write code and prose. They never decide the verdict or who must approve. The verdict is one deterministic function of the diff, the Rulebook at your main branch, and the recorded outcomes.
Does it work with our stack?
Hybrid does not care which language the app is written in. It cares that the app can run from its code: it starts in a Linux container from a short recipe, there is a seed of test data, outside services have a test mode or a stand-in, and a test account can sign in through a form. That fit check is the first conversation, and it is a session with your engineer, not a rewrite.
What if a verdict is wrong?
The guarantee is exact: every rule you wrote down is measured on every change that touches its area, every journey runs on the real app before and after, and anything unmapped or unmeasured is held for an engineer. Behaviour no rule names and no journey exercises is outside the guarantee, which is why coverage grows with every change your team makes.
When something slips through: revert and redeploy through your own pipeline; pull the category back with one rule edit; the reason is kept as a candidate rule that becomes policy only when an engineer approves it. A change with a migration or an outside effect is not undone by a revert, which is why those stay with an engineer.
How does a category get turned on, and off?
A category is a written rule: for example, changes inside these folders where no measured outcome changes are ready on the product owner’s confirmation. It is shadowed first, with Hybrid’s verdict beside every engineer review and agreement counted. Turning it on is an edit to that rule, and a rule edit is itself a change that needs an engineer’s approval. There is no confidence score and no streak that promotes a category on its own.
Turning it off is the same edit in reverse. Everything that shipped under it keeps its record.
Why not CODEOWNERS, branch protection and an AI reviewer we already have?
Keep them; Hybrid sits on top. CODEOWNERS routes by file path, so a wording change and a pricing change in the same file get the same reviewer. Hybrid routes by what the app did when it ran: the wording change leaves every measured total alone; the pricing change moves one and goes to the engineer. An AI reviewer gives an opinion on a diff it never ran, and can give a different one tomorrow.
What does getting started look like?
A fit check with your engineer. Then onboarding: Hybrid maps your areas and drafts the first rules and journeys with your team, and nothing counts until your engineer confirms it. Then your first real backlog item goes through the loop in approve-everything mode, with nothing shipping without an engineer.
From the first change you see two numbers: hours from request to live, and engineer minutes per change. The .hybrid/ folder lives in your repository in a format your team can read, and the record of every change is yours to export at any time.
