Skip to main content
After the first integration is green, keep it verifiable after the coding-agent conversation ends. Commit the sp-vise/ folder with the application, then run Vise as a read-only CI gate.

​
What the CI gate protects

The gate checks more than the feature currently being edited:
  • the active integration still matches its recorded scope
  • deterministic SDK and platform requirements still pass
  • required evidence and project sensors are present and current, including any retained runtime receipt
  • accepted organization policy remains current, authentic, and inside its lifecycle and trust boundaries
  • every previously completed Vise feature still holds against the current code
This matters when a later change passes for one surface but quietly breaks an earlier feed, comments, community, or chat experience.

​
Add the gate

Install the same Vise version your team uses for local work, then run:
Keep the command read-only in CI. Changes to contracts, attestations, baselines, runtime waivers, or policy selections should be deliberate reviewable changes made before the pipeline runs. For a more diagnostic pipeline, verify retained runtime evidence or the repository policy source in separate read-only steps before the composed gate:

​
Read the outcome

  • Green: the active work and all recorded completed features still hold.
  • Active failure: the current integration, required evidence, or project validation needs attention.
  • Earlier-feature drift: the active work passes, but a previously completed surface no longer does.
  • Release review required: when Passport comparison is enabled, the compliance checks pass but a person still needs to review the candidate’s release evidence.
  • Policy review required or blocked: the accepted policy source changed or crossed a lifecycle, signing-key, or rotation boundary; Vise returns the exact owner instead of accepting a successor automatically.
Link the CI output to the changed application code and committed sp-vise/ evidence so reviewers can reproduce the result locally.
MCP check_compliance returns the same compliance result and exit code with an additive customerOperations summary for build, Day-2, and release routing. The summary does not run sensors, write files, or turn advisory findings into a gate.
Teams using Integration Passports can add the same release comparison used during human review:
A ready result supports human release review; it does not record approval. See the command reference for exact exit codes and trust-policy options.

How Vise works

Understand result states and which ones need human input.

Review and release

Review the candidate evidence without confusing readiness with approval.