What is a CI gate for AI-written code?

A CI gate for AI-written code is a step in your pipeline that decides whether a pull request may merge, based on measured evidence rather than a report. It runs the suite, reads which changed lines actually executed, checks the result against a standard your team published, and signs what it saw so anyone can re-open the decision later.

What does a CI gate actually check?

Three things, in order, and the order is the point. Did the tests run? Did they execute the code this pull request added? Does that meet the bar this repository agreed to? A green check mark answers only the first question, which is why a green check mark on an AI-authored diff means less than it used to.

• Execution — the commands ran, with their exit codes and output hashes recorded.
• Coverage of the change — not the repository's overall percentage, but whether the new lines ran.
• The standard — the threshold the team published, applied identically to every repository.
• Integrity — nothing was edited between the evidence being produced and the verdict being computed.

Why isn't a passing test suite enough?

Because a suite passing tells you the tests you already had still pass. It says nothing about whether anything executed the lines your agent just wrote. An agent can add two hundred lines and a test that touches none of them, and every dashboard in your pipeline will be green — correctly, and uselessly.

That gap was tolerable when a person wrote the code and the same person wrote the tests, because they knew what they had skipped. It stops being tolerable when the author, the tests, and the summary of success are all produced by the same model in the same run.

Green is a measurement, not a claim — and the measurement most pipelines take is not the one anyone thinks they are taking.

How does signing change a CI result?

It makes the result portable and re-checkable. An unsigned CI log says a command ran once, somewhere, and it can be edited afterwards by anyone with write access to the artifact store. A signed receipt binds the command, its output, its coverage, and a snapshot of the exact repository tree into one artifact that fails verification if any byte of it changes.

The verdict computed from those receipts is deliberately *not* signed, because a verdict is arithmetic anyone should be able to re-run rather than an assertion to be trusted. What a signed receipt proves walks through what is inside one.

Is the gate a separate tool I have to install?

No — and this is the part teams get wrong when they build one themselves. The gate belongs in CI, not on developer laptops. In Relay it runs as a workflow action inside your own runner: the job exchanges its GitHub OIDC token for a short-lived signing credential with relay ci auth, produces receipts, and reports the verdict back. There is nothing extra for a developer to download, and no long-lived secret in your repository settings.

What does a CI gate not prove?

That the code is correct. A gate proves the checks you wrote ran against the code you have and that the evidence has not been altered — nothing about whether the checks were the right ones, and nothing about whether the feature does what the ticket asked. It is tamper-evident, not tamper-proof, and the distinction matters enough that we would rather lose a sale than blur it.

The CI guide has the workflow, and verify AI-generated code covers what the gate measures before a merge.