> ## Documentation Index
> Fetch the complete documentation index at: https://sdk.docs.xano.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Govern

> How the Xano SDK keeps shipping safe for a team and its coding agents: rules set once in the project and the pipeline, enforced on every change, and only a tested release reaching production.

Xano is one platform to build, run and govern AI-built software. This section covers the govern
part: the rules your team sets once, so that every change, from every person and every coding
agent, reaches production the same way.

Those rules live in places you already review. The project in git says what the backend is. The
CI workflow says which checks a change must pass. The release flow says how a change reaches
production: a build that came up on an ephemeral and passed its tests is stored as a release,
and only a release is promoted or deployed to a tenant. Nothing an agent writes on your machine
reaches production by any other route.

[AI code governance on xano.com](https://xano.com/ai-code-governance/) describes the approach.
The pages below are the commands and settings that put it in place.

## What the Xano SDK enforces

| Rule | How it is enforced |
| - | - |
| Only a tested release reaches production | `release create` cuts from an ephemeral, never from the Xano Engine. `promote` and `tenant deploy` take a release and nothing else. |
| A table change is never a surprise | `promote` refuses a release that alters a table (`SDK_SHARED_SCHEMA_CHANGE`, exit `2`) until someone passes `--allow-shared-schema-changes`. |
| Edits made in Xano are not overwritten silently | `deploy --to workspace` refuses to overwrite an object changed in Xano since the last deploy or pull (`SDK_WORKSPACE_CHANGED`, exit `2`). |
| Object identities do not drift | `npm run xano:check` fails the build when `xano/xano.lock` would change. |
| Going live is deliberate | `promote` lands on a new Xano branch. Live changes only with `--set-live` or `workspace branch set-live`, and `--expect-live` refuses if live moved. |
| An unknown outcome is never retried blind | A release write whose answer was lost exits `9` and names the read to run first (`resolveWith`). |

Every refusal exits with a code a script or an agent can branch on, and `--yes` waives a
confirmation, never a refusal.

## The pages in this section

<CardGroup cols={2}>
  <Card title="Schema changes" icon="table" href="/govern/schema-changes">
    Tables are shared by every Xano branch. Change them in steps that keep their data.
  </Card>

  <Card title="Drift" icon="code-compare" href="/govern/drift">
    Find edits made in the Xano editor, and bring them back into git.
  </Card>

  <Card title="Rollback and recovery" icon="rotate-left" href="/govern/rollback-and-recovery">
    Serve the previous release again, and recover a run that stopped partway.
  </Card>

  <Card title="CI/CD" icon="github" href="/govern/ci-cd">
    A complete GitHub Actions workflow: checks, previews, and releases on a tag.
  </Card>

  <Card title="Git, locks & merges" icon="code-merge" href="/govern/git-and-merges">
    What to commit, `xano.lock` conflicts, renames, and the review checklist.
  </Card>

  <Card title="Agent guardrails" icon="shield" href="/govern/agent-guardrails">
    What a coding agent runs on its own, and what waits for your approval.
  </Card>
</CardGroup>

## Next

[Schema changes](/govern/schema-changes): the one kind of change a Xano branch cannot stage.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.