For Admins

Velocity's approval chain ends with you. Reviewers can approve Submissions into a Build; only an Admin can promote a Build to a Version. These actions are Admin-exclusive across the entire org:

• Final sign-off on Builds — the single action that creates a new Version of a project.
• Create, archive, and configure projects (paths, branch rules, locked files, compile permissions).
• Manage compliance scan rules and required scan packs per project.
• Curate the MCP registry — which MCPs are allowed, at what scope, with what secrets.
• Provision CLI keys (Claude, Codex, Gemini) at the org level and assign per-project entitlements.
• Manage the org-approved Snippets library.
• Promote and demote roles (Developer ↔ Reviewer ↔ Admin) and transfer Manager.

Builds arriving from Reviewers land in the Admin queue at the top of the Build tab. Each row shows the parent Version, the Reviewer who promoted, the Submission count, and any escalation flags.

1. Open the Build to launch a Sign-off Session — a read-mostly working copy with the merged diff loaded.
2. Review the pre-review CLI summary, the Reviewer's notes, and the compliance scan results bundled with the Build.
3. If anything fails the project's policy, reject the Build with a reason — it returns to the Reviewer queue.
4. Set the new Version number. Velocity defaults to the project's versioning scheme (semver, calver, integer) but you can override.
5. Hit Sign off. The new Version is created, every linked session is told to rebase, and the optional GitHub push fires if configured.

Project settings are where the bulk of your configuration lives. Each pane is per-project and inherits sensible org-level defaults that you set in the org admin area.

• General: name, description, versioning scheme, optional GitHub remote for one-way push on sign-off.
• Access: assigned users and teams, role overrides, locked file paths that require Admin sign-off.
• Review: pre-review CLI, required reviewer count, blocking-thread rules, escalation triggers.
• Compile: which roles may compile, which targets are allowed, and the JS/TS extractability acknowledgement.
• Compliance: scan packs, required-pass thresholds, suppression rules and their expiration dates.
• Integrations: per-project MCPs, CLI key bindings, webhook endpoints.

Velocity ships scan packs aligned with the frameworks enterprise buyers actually ask about: SOC 2, HIPAA, PCI-DSS, GDPR, and ISO 27001. Packs are bundles of tuned Semgrep, Trivy, and Gitleaks rules plus a License-Finder allowlist.

• Enable one or more packs per project. They run automatically on every Submission and again on Build promotion.
• Findings appear on the Compliance tab with severity, rule provenance, and a Reviewer-visible explanation.
• High-severity findings block Build promotion by default. You can suppress with a written reason and an expiration date — both go to the audit log.
• Custom rule packs sit alongside the shipped ones; YAML for Semgrep, your own License-Finder allowlist.
• Compliance reports export to PDF for auditors. The export includes the rule hash, the suppression history, and the signing Admin's identity.

The Snippets tab is an org-approved code library. Admins curate it; Developers pull from it inside any session. Use it to standardize boilerplate — auth middleware, logging setup, the team's preferred Postgres connection wrapper, the way you do feature flags.

• Add snippets from any session via Save to Snippets — they enter a draft state until an Admin publishes.
• Snippets are versioned. Updating a snippet bumps its version; existing pastes are unaffected.
• Tag snippets by language, framework, or internal taxonomy. Search is full-text plus tag filter.
• Per-project visibility lets you publish snippets that only show up inside specific projects.

MCPs and CLI keys are the two integration surfaces Developers and Reviewers will reach for constantly. You control both.

• MCP registry: add an MCP server once at the org level; choose which projects expose it; choose whether secrets are org-shared or per-user.
• Scoping: MCPs can be marked read-only, write-allowed, or compile-only. Sessions enforce the scope.
• CLI keys: register Anthropic, OpenAI, and Google keys at the org level. Pick which CLIs use which keys per project.
• Personal keys: Developers can optionally bring their own keys for personal CLI usage. Org policy decides whether this is allowed.
• Usage and audit: every MCP call and every CLI request is logged with cost attribution and the originating session.