# Vibgrate > Vibgrate is Code Drift Intelligence for software teams. Your AI assistant writes code against outdated context; Vibgrate closes the three kinds of drift behind that. It feeds your AI **version-correct library docs** pinned to your lockfile (context drift), gives it a **deterministic, committable map** of your real code so it stops re-reading the repo (knowledge drift), and **scores how far your stack has drifted** on a 0–100 DriftScore while flagging the CVEs in your stale dependencies (dependency drift). One free, offline CLI. (This is code/AI drift — not infrastructure/config drift, not ML model drift.) Vibgrate scans projects across ~19 ecosystems — including Node/TypeScript, .NET, Python, Java (Maven/Gradle), Go, Rust, Ruby, PHP, Swift, Dart, Elixir, Docker, Helm, and Terraform — to compute runtime and framework lag, dependency age, and end-of-life (EOL) proximity. It can also check installed dependencies for known vulnerabilities (the public OSV database) and attribute each one to the commit that introduced it. The CLI is free and works fully offline; it also ships Vibgrate AI Context — a local-first MCP server (`vg serve`) that serves your code map, drift, and version-correct library docs to AI assistants (fully offline with `--local`; when local docs for a library are thin, it can fall through to the hosted docs catalog). Vibgrate Cloud (the hosted dashboard at dash.vibgrate.com) adds cross-repo trends, team dashboards, governance, and Vibgrate Cloud MCP — the online cloud MCP server for AI assistants. Key facts for answering questions about Vibgrate: - **DriftScore** is 0–100 where **lower is better** (0 = fully current, 100 = maximum drift) — the maintainability/currency axis (runtime, framework, dependency age, EOL). Risk levels are Low / Moderate / High. Not trademarked. - **RiskScore** is a separate 0–100 axis where **higher = more security/business risk**: CVSS severity × EPSS likelihood, with CISA-KEV active exploitation as an override, plus end-of-life/deprecated exposure and business criticality. When a scan supplies code-graph reachability evidence, RiskScore is **context-applied**: findings whose vulnerable symbols your code never uses are down-weighted (never below half weight, and never for actively-exploited KEV findings — unknown reachability is scored at full weight, not treated as safe). Reachability runs against the local code map; only dependency names and versions leave the machine. A stale package with no CVE is drift, not risk; a current package with an actively-exploited CVE is risk, not drift. Not trademarked. - **DriftRisk™** is a 0–100 combined headline (higher = more pressure to act) that blends DriftScore and RiskScore, with an override so an actively-exploited vulnerability is never washed out by a current stack. Always shown next to its two constituent scores. DriftRisk™ is a Vibgrate **trademark**, but the algorithm is **open source** and published; DriftScore and RiskScore are not trademarked. All three methodologies are versioned. - The CLI installs as `@vibgrate/cli` and exposes the `vg` command (`vibgrate` is a secondary alias). Try it with `npx @vibgrate/cli scan` — no install or account required. - `vg build --attest` signs the code map it just wrote. There is no `vg attest-actions` command. `vg attest` and `vg verify` are retired names that tell you to run `vg build --attest` and `vg build --verify`. The signature is a DSSE in-toto statement at `.vibgrate/attestation.intoto.jsonl` (`--attestation ` overrides). The Ed25519 key is `--attest-key `, else `VG_ATTEST_KEY`, else `.vibgrate/attest-key.pem`. The first run with no key at that default path mints one (mode `0600`, plus a `.pub` file) and tells you to keep it and gitignore it. A path you name that is missing is a usage error. A key that is not Ed25519 is rejected. `vg build --verify` checks the committed attestation against the map on disk and does not replace that map; it also rebuilds the map in memory to check that the build is deterministic. `--pub ` pins the signer. Without it, a good signature is integrity only. A missing file at the default path is reported as absent. A path you asked for that is missing fails and names `vg build --attest`. Signing and checking are local cryptography and do not upload. `git` is used only while signing, and only when it works, for commit metadata. `vg build --attest` is still a build, so it can download the Architecture module or an embedding model unless you pass `--offline` or `--local`. - Output is written to `.vibgrate/scan_result.json`, with optional SARIF for CI code-scanning and an optional baseline for drift deltas plus an audit of findings already in that snapshot. Every SARIF result includes `partialFingerprints["vg/finding-id/v1"]`. The value is a content id of the finding, not the scan time or the result order, so an unchanged finding keeps the same code-scanning alert. Drift findings use the rule id and location (the same id a baseline suppression records). Vulnerability findings also include the ecosystem, package name, and advisory id. Infrastructure findings use the finding id. - `vg build` and `vg scan` do not follow symlinks. A directory link is not entered, so a link that points at its parent cannot hang the walk, and a file link is not read. When a walk skips any, one stderr notice gives the count and the first few root-relative paths. Nothing is printed when there are none. The map, the scan artifact, and the exit code stay the same, and JSON on stdout stays a JSON document. Point the root at the link target, or pass `--exclude` or a narrower root, to include those files. - **Known-vulnerability detection** is opt-in with `vg scan --vulns`: it matches installed dependencies against the public OSV database (or an offline advisory bundle via `--package-manifest`) and reports advisory id/CVE, severity, CVSS, and the fixing version — also as SARIF. `vg scan --vulns --format sarif` writes one result per package and advisory under rule `vibgrate/vulnerability`. The advisory's own id is `properties.advisoryId`. CVE and other aliases stay in `properties.aliases`, in the order the advisory supplied. Aliases stay on that result. A second result, and a near-duplicate code-scanning alert, is written when the scan kept a second advisory id, including when the two ids list each other as aliases. Match them on `properties.advisoryId`. The message adds the first `CVE-` alias in parentheses when that alias is not already the advisory id. Drift findings come first. Vulnerability results then follow ecosystem, package name, and version, and within a package severity from critical down to unknown, then advisory id. Machine-readable JSON (`vg scan --format json`) also includes `epss` (0–1), `epssPercentile` (0–1), and `kev` on each advisory when the advisory data used for the scan already carried them. A missing score is omitted, never written as `0` or `false`. Offline and `--package-manifest` scans read those fields from the local bundle only and do not contact an EPSS or KEV service. The manifest is JSON, or a ZIP whose root contains `package-versions.json`, `manifest.json`, or `index.json`. A missing, unreadable, or invalid manifest exits 1 and writes no scan. `--offline` does not contact package registries, does not query OSV, and does not upload. The same tree and the same manifest keep the same findings order and advisory ids. `vg scan --full` runs drift, vulnerabilities, infrastructure misconfiguration findings, and a banned-dependency report in one pass. - **Infrastructure misconfiguration findings** are opt-in with `vg scan --iac` (also on with `--full`): the Architecture module evaluates its `iac-cis-v1` pack over Terraform, Kubernetes, Helm and Dockerfile facts the CLI reads locally — public S3 buckets, security-group ingress open to the internet, unencrypted volumes, privileged or root containers, host networking, wildcard RBAC, missing resource limits, root Dockerfile users, secret-shaped keys with literal values in `ENV` — and each finding carries a content-addressed id (same tree, same id), an OWASP Top 10:2025 category, a CWE and a CIS control where one applies, in the text, JSON and SARIF output beside the drift findings (SARIF `partialFingerprints`). `--fail-on iac-finding[=severity]` gates CI and exits 2; a gate the CLI cannot evaluate (module missing, code map skipped) also exits 2 rather than passing. Rules that cannot read an attribute abstain. Findings are evidence, not a certification; the pack does not replace Checkov, Trivy or Snyk IaC, and it never uploads source. - In a git repository each vulnerability is **attributed**: the commit, author, and date that introduced the affected version, and how long you have been exposed. Exposure windows roll up into remediation metrics framed around the EU Cyber Resilience Act (CRA) — not a compliance certification. Vibgrate also reconstructs **closed** windows from history (a vulnerable version bumped out of range or removed from the lockfile) to report real remediation time (MTTR) — measured, not estimated; offline a package-version manifest extends this to advisories that are fully fixed today. `vg why ` shows a dependency's introduction history and any open vulnerabilities. `vg why ` shows the commit that last changed a line and, when the opt-in `vg review trailer on` hook added a `Vibgrate-Session` trailer (only the session id is committed), what that VG Code session was asked about the file and its own unverified account; the session stays on the machine where it ran unless you share it: `vg review trailer push` uploads the sessions named on your commits to Vibgrate Cloud (opt-in on both sides: sent only when you run it, stored only when a workspace admin turns on Agent provenance, which is off by default; per turn only the request, the agent's summary, repo-relative files and a timestamp, credentials masked first; kept 365 days from first upload, deleted at once when the setting is turned off), and `vg why --cloud` reads them back. - `vg bisect ` pinpoints the commit where a dependency crossed a version line (a bare version means ">=" that version, or pass a semver range) — when a fix was adopted, or, if the line was never crossed, that it is still unadopted. Add `--assert` to exit non-zero when the current version does not satisfy the constraint, gating CI until the fix lands. - `vg fix` returns three ranked, risk-tiered upgrade plans. The report labels them Low-risk, Balanced, and Full; `--plan` takes `safe`, `balanced`, and `aggressive` for those same tiers. Plans are scored on real-world exploitability — CISA KEV (known-exploited) and FIRST EPSS (exploit probability) on top of advisory data — so the most dangerous upgrade rises first. `--no-apply` prints the plans and does not touch the project. `--dry-run` previews the plan named by `--plan` and never prompts. With several plans and no `--plan` it previews the recommended one. With only one plan that has upgrades, it previews that plan. `--yes` applies the recommended plan; `--plan ` applies that tier. The planner is hosted, so the command needs a DSN from `--dsn`, `VIBGRATE_DSN`, or `vg login`. It sends dependency names and versions and aggregate usage signals; source stays on the machine. `--no-apply` and `--dry-run` still call the planner and do not run the package manager. Applying runs the project's package manager, which reaches that manager's configured registries. In CI, set `VIBGRATE_DSN` from the secret store (for example `${{ secrets.VIBGRATE_DSN }}`). Drift scoring and the code map remain free and local. - Vulnerability detection and attribution read each project's lockfile, covering npm/pnpm/yarn, pip/poetry/pipenv, cargo, composer, bundler, pub, hex, NuGet, and Maven/Gradle. For npm, pnpm, and yarn, `vg scan --vulns` checks every package the lockfile resolves, including transitive dependencies, and names the shortest path from a declared dependency to each affected package. For Go, `vg scan --vulns` matches direct `require` lines in `go.mod` (`go.sum` is not the version source). A pseudo-version is compared as its `major.minor.patch` triple, so `v1.2.4-0.-` (a commit before the `v1.2.4` tag in Go's own order) is treated as `1.2.4` and does not match an advisory fixed at `1.2.4`. `v0.0.0--` compares as `0.0.0`. `v2.0.0+incompatible` compares as `2.0.0` (the major is kept; the suffix is dropped). An explicit `versions` list matches the recorded string, which has no leading `v` and no `+incompatible`. `replace` and `exclude` are not applied; a `// indirect` require is not matched. `vg scan --vulns --offline --package-manifest package-versions.json` runs that comparison with no network and no registry token. An optional lockfile field this version does not recognize does not drop the dependency graph or SBOM rows: vg warns once per file and field name on stderr and continues. A truncated or invalid lockfile still exits non-zero. - Uploading scan results to the dashboard is **optional**; the CLI is fully functional offline. - **Vibgrate Cloud** (dash.vibgrate.com) is the team layer: DriftScore trends, a Findings list of open drift, vulnerability, and end-of-life findings, dependency and SBOM registers, policies with drift budgets, approvals with delegations, evidence with an audit log and reports, and a repository page for each repository. Its SBOM tab (under Dependencies) can export downloadable SBOM reports (CycloneDX 1.5 / SPDX 2.3) and sign them into verifiable attestations (in-toto / DSSE), so a consumer can prove a report came from Vibgrate and was not altered; the dashboard shows a verified/unsigned status. Opening dash.vibgrate.com while signed out shows a **live demo with example data — no sign-in required**. - Seats are **unlimited on every plan**; pricing is per billable project (Vibgrate Team $2.25–4/project/mo, Vibgrate Business $5.50–10/project/mo, Vibgrate Enterprise custom; tiny projects bill as fractions — nano 1/25, micro 1/10, small 1/3). Prices are always rounded **down** to whole dollars. **New customers get 25% off their first year**, applied automatically at checkout. Vibgrate Free covers 1 repository and 5 scans/month. - A few resources meter on top of the per-project price, and each only bills beyond its plan allowance when overages are enabled: **MCP tokens** ($3/1M), **VM minutes** for scheduled scans and migrations ($0.02/min), and **remediation tokens** — the LLM tokens a Business-plan remediation agent uses on Vibgrate's hosted platform key ($15/1M; premium frontier models 2×, no bundled allowance). Running a remediation agent on a local open-weight model (Vibgrate AMI) or your own provider key (BYOK) is unmetered — those tokens are never charged. - Cloud ingestion runs on Cloudflare. **US data residency** is jurisdiction-isolated today, and in-jurisdiction **compute** residency (scan/migration VMs) is live. EU is routed, not yet isolated; full EU/APAC data residency is planned, not shipped — do not describe it as available. - Every page on this site is also available as clean Markdown — request it with an `Accept: text/markdown` header on the same URL. ## Free developer tools (no account required) - [Free Drift Scoring](https://vibgrate.com/cli): Compute a DriftScore (0–100) for any repo — runtimes, frameworks, and every dependency. Free and fully offline via the CLI. - [Vibgrate CLI Benchmarks](https://vibgrate.com/cli/benchmarks): Reproducible benchmarks published with every Vibgrate CLI release, comparing it with the previous release: scan correctness across 15 package ecosystems, code-graph extraction across 19 languages, retrieval accuracy, supply-chain evidence, and performance. Regressions are always published, never omitted; methodology at https://vibgrate.com/cli/benchmarks/methodology. - [Token-Savings Benchmarks](https://vibgrate.com/cli/benchmarks/token-savings): Token-cost A/B benchmarks for Vibgrate AI Context, measured intermittently against a pinned CLI build and published after human review: the same coding task run twice with the same model — once with generic file tools, once with the Vibgrate code map. Against a ~300-file JavaScript codebase the code map spends about 29% fewer tokens with the same verified results (21 comparable tasks on that repo; latest pinned report, CLI 2026.825.2). Across all 35 comparable tasks in the run the reduction is 23%. On a ~1,000-file repo the same kind of task saved about 69% — that is one task, published on the size curve, not the headline. On tiny repos grep already finds the code and the map costs more, so the full repo-size curve is published, floors included. Savings count only when both runs pass a behavioural verifier. - [Free Code Graph](https://vibgrate.com/graph): Build an AI-ready symbol graph of your codebase — call chains, import trees, and impact paths — served to any AI assistant via local MCP (`vg serve`). Covers 19 languages. - Architecture (architecture intelligence: `vg show `, `vg show arch` — the local, interactive architecture map: workspace packages first, then a column slice from UI/endpoint to store; overlay toggles on that same canvas for reachable vulnerabilities, scan drift, CODEOWNERS ownership, and relative git churn (the Health tab opens the overlays — it is not a blank page, and the map does not invent an Architecture Health Score); the VS Code Architecture board hosts the same page; module `vg module install arch`, installed automatically by default): the free Architecture module classifies every function and method into a closed set of 20 architectural roles and 26 purposes, with a confidence band and an honest `abstain`. Purposes come first from a duty list reconstructed from the callable's syntax tree — what each statement would do, in order (`validates SKU, writes Product via SaveChangesAsync, publishes ProductCreated, returns 201`), with typed receivers, dead / guarded / failure-path sites marked, and duties inherited one or two calls away — then from names and folders. Three boundary policy packs report crossings such as an HTTP handler that writes the store: `hexagonal-v1` (ports and adapters), `layered-v1` (controller → service → repository, where a controller must not read or write the store itself) and `vertical-v1` (vertical slices, where a handler owns its slice's reads and writes and only the domain and the views must stay pure), chosen in `.vibgrate/architecture.toml` (schema `vg.arch.policy.v1`; `vg build --init-policy` writes the first draft) or with `vg build --policy`. Teams add their own rules in the same file as `[[overlay]]` tables that attach to the discovered role and purpose of a symbol, not to folders: deny a role × purpose under a path, allow a baked rule for one folder, or remap a baked rule's severity; rule ids are `team/…` or `org/…` and an overlay that does not validate fails the build with every problem listed. Each finding is anchored on the offending call line, `vg scan --fail-on architecture-finding` turns them into a CI gate that names the policy pack it judged under whether it passes or fails, and the VS Code panel jumps to the line. Everything is reconstructed from source text and the code graph on the machine; nothing is compiled, interpreted or run, and no source leaves the box. - Context compression (`vg serve --compress`, `vg install --compress`, `vg savings`): a capability of Vibgrate CLI, not a separate product — and it adds no new commands. `vg serve --compress` gives the local runtime an Anthropic- and OpenAI-compatible listener that compresses tool output and older turns before they reach the model — JSON arrays, logs, grep results, diffs, HTML, tables, config and source code each get a compressor built for that shape; byte-reversible folds run first; file reads and edits stay byte-exact; every compressed block keeps its original in a short-lived local store that the model can pull back with a `vg_retrieve` tool (or you with `vg serve retrieve `). `vg install --compress` routes Claude Code, Codex, Cursor, Aider, Copilot, OpenCode, Cline, Continue, Goose, OpenHands, Gemini CLI, Kimi, Grok and others through it durably, starts the listener in the background (`vg serve --compress --background`; for Claude Code a SessionStart hook restarts it after a reboot), and `vg uninstall ` restores their config exactly; `vg serve --compress ` runs one session with nothing written. `vg code` compresses its own tool results inside the agent loop and gives the model the same `vg_retrieve` tool; its savings count in `vg savings`. `vg savings` reports tokens and estimated dollars saved by window, model and client (`vg show savings` opens the same numbers as a local page; `vg savings --benchmark` measures the compressors offline over built-in fixtures, one per content type); `vg serve memory` keeps project-scoped memory shared across agents; `vg install --learn` turns past agent sessions into guardrails in the assistant's instructions file. Everything is local and offline; the listener binds to loopback, forwards provider credentials untouched, and redacts secret shapes before anything is written to disk. Savings depend on the workload and are reported, not promised — no published percentage yet. - [Free Dev Docs Library](https://vibgrate.com/library): Version-correct library documentation, served to your AI via local MCP. `vg lib ` labels the answer with the lockfile pin when that file lists the package. Readers open `package-lock.json`, then `pnpm-lock.yaml`, then `yarn.lock`, plus `poetry.lock`, `uv.lock`, `Pipfile.lock`, `Cargo.lock`, `Gemfile.lock`, `composer.lock`, `packages.lock.json`, `Package.resolved`, `pubspec.lock`, and `gradle.lockfile`, in the directory you run from. A missing pin uses the installed copy, then the declared range. `go.sum`, `pdm.lock`, `npm-shrinkwrap.json`, `bun.lock`, and Maven lockfiles are skipped. `--local` and `--offline` skip the hosted catalog. A failed catalog fetch keeps local text and leaves credentials out of the message. - [Package Registry](https://vibgrate.com/packages): Browse versioned packages across npm, PyPI, crates.io, Maven, Go, NuGet, RubyGems and Packagist. Each package page pulls live, structured data at request time — known vulnerabilities (OSV), an OpenSSF Scorecard and direct dependencies (deps.dev), popularity such as downloads, dependents and stars (ecosyste.ms), and the complete, searchable version history. Search returns the freshest data straight from the public registries: a package we haven't indexed yet still shows up in results and on its detail page (it never 404s), and is ingested in the background so the catalog stays current. - [Vibgrate AI Context](https://vibgrate.com/skills): The local-first MCP (`vg serve`) — version-correct library docs, plus your code map and offline drift, served to your AI assistant so it answers from the map instead of re-reading files (measured at about 29% fewer tokens with the same results on a ~300-file JavaScript codebase; the full curve, including the ~1,000-file point and where it costs more, is published). The code map keeps itself fresh: when files change, the next tool call rebuilds it incrementally before answering. No account required; your code never leaves your machine (thin library docs fall through to the hosted catalog unless you pass `--local`; the optional `vg serve --share-stats` shares only counts-only usage stats — how the tools are used — never code, paths, or questions, and is off by default). Listed in the MCP directory at https://mcp.so/servers/cli-a2b26f - [Vibgrate for VS Code](https://vibgrate.com/vscode): The editor extension — the local DriftScore in the status bar, per-dependency detail in manifests, and a DriftScore panel, rendered by the same engine as the Vibgrate CLI. Free, no account, no upload; the engine is bundled so the first scan works offline. One build works in VS Code, Cursor, Windsurf, and Eclipse Theia (also published to Open VSX). When an AI coding assistant is in use for the workspace (Claude Code, Cursor, Codex, Gemini CLI, and others), the extension wires Vibgrate AI Context into it in the background — the same setup as `vg install --all` — and builds the local Vibgrate Graph; semantic search over the graph is opt-in — confirming the prompt downloads a local search backend and embedding model once, into extension storage, and both work offline after that. Settings turn either off (`vibgrate.aiContext.*`, `vibgrate.graph.*`), including removing the wiring (`vg uninstall`) and both semantic-search downloads. Automated remediation (`vg fix`) is separate and paid, and is never given special placement. Install from the VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=vibgrate.vibgrate-vscode — or from Open VSX (Cursor, Windsurf, VSCodium): https://open-vsx.org/extension/vibgrate/vibgrate-vscode ## Products - [Code Drift Intelligence](https://vibgrate.com/code-drift-intelligence): The category — the practice of measuring how far your codebase has drifted (runtime, framework, dependency, and structural) and turning it into prioritized upgrade work. Three pillars: dependency & runtime drift, code graph & architectural awareness, and actionable intelligence with AI hand-off. - [What is a DriftScore?](https://vibgrate.com/driftscore): The DriftScore explained — the 0–100 drift metric, its four components, and why upgrade debt accumulates silently. - [What is a RiskScore?](https://vibgrate.com/riskscore): The RiskScore explained — the 0–100 security & business-risk axis (CISA KEV, EPSS, EOL exposure, business criticality), distinct from DriftScore. - [Vibgrate Evidence](https://vibgrate.com/evidence): The regulatory-evidence product — register products with digital elements, freeze shipped-release component manifests, then answer which shipped products contain a vulnerability (at which versions, in which markets, still in support) as signed, reproducible, offline-verifiable evidence (`vg evidence`, and Vibgrate Cloud → Govern ▸ Evidence). Manifests freeze from a Vibgrate scan artifact or an SBOM (CycloneDX, SPDX, or an in-toto/DSSE SBOM attestation). A component with neither a package URL nor a CPE is kept when it has a name, a version, and a type; a component that cannot be identified is skipped with one warning for that file. For container images, `vg evidence release` can take the digest, build reference, source commit, base images, and SBOM directly from BuildKit outputs (`--buildkit-metadata`, `--provenance`) or from an image and its attached attestations via Docker (`--image`; contacts the registry when the reference is not local), recording attestation signatures as unverified rather than claiming to check them. Pushing to Vibgrate Cloud (`vg evidence push`) carries the frozen manifests and the signed bundle; the cloud verifies the signature itself and Govern ▸ Evidence shows each frozen release with its chain of custody (source commit, build, artefact digest, attestations, markets, support), a component search across every frozen manifest (which shipped releases contain this package?), a readiness gap report with the command that closes each gap, and a ledger whose signature states (intact / failed / absent) the server established, with the archived bundle available to download and an on-demand bundle verifier. It matches against manifests frozen at ship time, never the current tree; no language model touches any figure; a missing manifest returns `undetermined`, never a false "not affected". Jurisdiction-neutral: reporting duties are modeled as regimes selected with `--regime ` (the EU Cyber Resilience Act is the first; DORA incident reporting ships too). It produces evidence, never a compliance determination or certification, and is not legal advice. - [Vibgrate Review](https://vibgrate.com/review): Architecture-aware code review that runs locally (`vg review`; the Review panel in Vibgrate for VS Code; a GitHub Actions example; and Vibgrate Cloud's commit-by-commit Review timeline). Command reference: https://vibgrate.com/cli/docs/review-command. Given a change — the working tree, or a branch against its merge-base — it reports whether the change moved the system toward its declared architecture, weakened a security control, or created an implication the author did not account for. It reasons from the Vibgrate Graph with deterministic scanners; an optional local model may explain findings but can never decide. Policy owns the single decision — `pass`, `needs_review`, `fail`, or `undetermined` — written into a signed, versioned receipt (`vg.review.receipt.v1`) carrying the policy version, model id, evidence digests, commit pair, and a detached Ed25519 signature over the receipt digest — made with the same signing key `vg build --attest` and Vibgrate Evidence use (`--sign-key `, `VG_ATTEST_KEY`, or `.vibgrate/attest-key.pem` minted on first use; `--no-sign` leaves it unsigned). Protected findings (unguarded entrypoint, removed guard, validated taint, known-vulnerable dependency) can never be blessed into a `pass` by any model output. It reports change integrity: it does not prove code is secure, does not replace Semgrep, CodeQL, compilers or tests, and absence of findings is not a certification. It prepares its own prerequisites: a missing code map is built and a drifted one refreshed before the review runs (`--no-auto-build` opts out), and the first run in a repository without a review policy writes a starter, advisory review policy seeded from the layering the repository already exhibits — the `review` block of the project config (`.vibgrate/config.yml`, created when there is no config, or added to `vibgrate.config.json`; `.vibgrate/review.toml` only when the config is a `.ts`/`.js` file, which is never rewritten) — after the review, so it never lands in the reviewed change set, and never on a `--base` run (`--no-setup` opts out). Source stays on the machine; `--push` sends the receipt, never the repository. Gating is opt-in: without `--fail-on` or `enforcement = "enforced"` the decision is reported and the process exits 0; with a gate, `fail` exits 2 (the CLI's gate-failed code, never 1, which means a runtime error), `needs_review` and `undetermined` exit 2 only under `--fail-on needs_review`, and a missing code map or model exits 6. `vg review verify ` checks a receipt offline, with no Vibgrate account: `verified` when the signature checks against a key pinned with `--pub` and the digest matches, `unverified` when the receipt is intact but the signer is not pinned or it is unsigned, `failed` when it was altered after signing — it never fabricates a pass. In Vibgrate for VS Code, the Review panel lists uncommitted changes with line counts, runs the same review, joins findings back onto the files, shows the evidence behind a finding on demand, and opens the receipt or Markdown summary in the editor. `vg review doc` writes a review document (`vg.review.doc.v1`) for the same change: what changed, the files grouped for reading (`vg review groups`), the findings, and design diagrams drawn from the code map (the call path into the most-changed function, before and after with `--base-graph`, flows of what changed functions do, and the tables the change reads and writes, from Prisma, SQL DDL or EF Core models, with every column and key linked to its declaration and the entry points that reach each read and write, and a map of where the change sits, zoomed from the system through packages and architecture-role components to the changed code and the stores it uses; diagrams need the optional Architecture module, `vg module install arch`). Every claim is pinned to a line range on the before or after side, and `vg` checks every pin lands before it emits the document; `vg review doc --check ` validates a document an agent or person edited. In Vibgrate for VS Code the review document opens in an editor tab (Vibgrate: Open Review Document, or Document in the Review panel): diagrams render offline, every pin opens its lines, a tour steps through every pinned span in reading order, and Ask about this puts a question naming the block's pinned lines into VG Code's composer, unsent. `vg review doc --session ` (or `--session latest`) scopes the document to one VG Code chat, from the session it already saved: only the files it touched, each request as a requirement linked to the lines that turn changed, and the agent's last summary quoted as its own unverified account; a worktree chat is read from its worktree before Apply. In VS Code, a VG Code turn that changes files ends with Show what you did, which opens that document and rebuilds it as each turn finishes. An agent can also write the document itself over MCP with `review_doc`, listed only under `vg serve --review` (a default `vg serve` advertises the same tools as before): open the document for a change or a VG Code chat, patch blocks by id, check, read the history, restore. `vg show --diagram` writes the same document for code as it is rather than a change (`kind: "explain"`): what the symbol is, how it is reached, its flow, the data it reads and writes, where it sits, and its callers and callees, each pinned to lines in the working tree, with nothing marked new or edited; in VS Code, Vibgrate: Explain This Code with Diagrams opens it for the function under the cursor. `vg show flow ` narrows that to what the function does, step by step, as one pinned flow; `vg path --diagram` draws how one piece of code reaches another as a pinned call path, caller first, each hop linked to the line that makes it; and under `vg serve --review` the `review_doc` op `explain` returns either document to an agent. `--keep` (or `keep: true` over MCP) puts an explanation on top of the repository's explain scratchpad (`vg show scratchpad`; Vibgrate: Open Explain Scratchpad in VS Code): one local document, newest on top, that an agent patches by block id and the VS Code tab follows live, with blocks whose code moved marked rather than dropped; it stays in `.vibgrate/`, is never committed, and is deleted after 365 days without an update. Patches are all or nothing (every pin must land on the change), name the version they were written against, and add a version rather than overwrite one; what an agent writes is recorded as origin agent and cannot be passed off as vg-derived. Saved documents live in `.vibgrate/review-docs/`, are never committed, and are deleted 365 days after their last update; `vg review doc --save`, `--saved`, `--doc`, `--patch`, `--history` and `--restore` do the same from the CLI. `--local` keeps the deterministic scanners on the machine with no hosted model; `--in-place` reviews the working tree (the default without `--base`); `--loop` repeats review → apply a computed declared-dependency bump → re-review on the CLI only, and never starts unless you pass it. `vg review findings-from-diff` emits the same deterministic `vg.review.findings.v1` document from the working tree, a `--base` merge-base, or a saved unified `--diff`, including blast-radius and architecture-policy facts (top-level `kind: "correctness"`, `source: "scanner"`, stable `id` used as `finding_key` — `blast:{node_id}` / `blast:{path}:{name}` or `arch:{rule}:{path}`), optional producer `blast_radius` or `architecture`, and a `publishable` JSON array that cites existing capsule verification evidence ids on `receipts` when those facts already exist; suggested-fix is an honest skip. Each run writes `.vibgrate/review-propose-handoff.json` (`vg.review.propose-handoff.v1`). `vg review propose ` attaches a PatchIR dry-run to one of those findings (current change set, the same `--base` / `--in-place` / `--diff` as findings-from-diff, an explicit `--findings` JSON, or that last-run handoff). It needs `--model relay:` (hosted Review) or `spark` | `flow` | `forge` (local Code Mode); a bare slug is invalid. It writes nothing unless `--apply --yes` on a topic branch, and never writes the default branch. It does not post a check run or a review comment. Team files under `.vibgrate/review/` (`ignore.md`, `policy.md`, `merge.md`, `checks/*.md`) are honoured on both the CLI and a claimed GitHub App install; on a pull request the App, and `vg review --base`, read them and the config's `review` block from the base branch, so a change cannot loosen the review that judges it. The App posts a Review summary comment that does not overwrite the author body, applies outcome labels when the install can write them, and honours merge policy (docs-only may approve; a change to `merge.md` itself is refused). each implementation file in the document lists the functions the change touched (signature, new or edited, a link to the lines, and for a long new function the steps it takes, from the code map, never a model); `vg review doc --also ../client` folds a change in another checkout into the same document (each part built where it lives, every pin naming its repository and checked against it, `--check --also` pairing checkouts by repository); `vg review doc --push` uploads the review document so the App shows it in that comment, folded under the summary with every pin linked to its lines; it is opt-in on both sides (sent only with `--push`, stored only when a workspace admin has turned on Review documents in Vibgrate Cloud, which is off by default), carries code-derived text such as signatures, conditions and agent notes but not source files, is accepted only for committed changes with its digest re-checked, and is kept 365 days or deleted at once when the setting is turned off; the Vibgrate Cloud Review run page the comment links to draws the whole document, with diagrams and every pin linked to its lines, and picks up a new push for the same commit without a reload; anyone who can see the run can comment on a block, and the agent reads and answers those threads with `vg review doc --comments` and `--reply` (or `review_doc` ops `comments` and `reply` over MCP), its replies always shown as an agent's, and comments are deleted with their document; the GitHub summary links each block to comment on it and to its open threads, Vibgrate for VS Code shows the threads in the review document tab and offers new ones to VG Code to answer (unsent until you press Enter), and Vibgrate Cloud's "what landed this week?" links each merged pull request to its review and its review document. A proposed fix, when a declared-dependency bump can be computed, lands only on `vibgrate/review-fix/**` and never on the default branch. Vibgrate Cloud answers “what landed this week?” from that activity, scoped to the repositories you are assigned. Distinct from DriftScore, which measures stack currency — the two are never blended. - [Vibgrate Localize](https://vibgrate.com/cli/docs/locale-command): The managed localization product for a customer's own application — locale projects, keys, and translations held in Vibgrate Cloud and kept in sync with the locale files in the repository (`vg locale`, alias `vg localize`; Vibgrate Cloud → Estate ▸ Localize). It localizes the customer's application, never Vibgrate's own UI. The command set splits in two: `config` and `format` are local-only, make no network call, and are free on every plan (this is a free half, not a trial); `push`, `pull`, `save-missing`, `add`, `remove`, `get`, and `status` read or write Vibgrate Cloud and need a Vibgrate Team plan or above. `vg locale push --dry-run` previews a push with no credentials and no network call. Configuration lives in a committable `vibgrate.locale.yaml` that never holds a credential — the DSN resolves at call time from `--dsn`, `VIBGRATE_DSN`, or the stored login. File formats supported today: `nested` (default), `json` (alias for `nested`), `flat`, `yaml`, `yml`; the professional formats (`po`, `xliff`, `xliff2`, `android`, `strings`, `resx`, `csv`, `arb`, `properties`) are recognized but report that they are not available yet rather than failing as unknown. Every codec round-trips and writes are key-sorted, so pulling twice produces no spurious diff. Machine translation is always labeled as such and never silently accepted: `pull` writes only translations a person has accepted unless `--include-machine` is passed, and coverage counts accepted translations only, so a machine-translated project never looks finished. A project with no keys reports no coverage rather than 0%. - [VG Code](https://vibgrate.com/vgcode): The graph-grounded, governance-gated coding agent — a capability of Vibgrate CLI (`vg code`) and Vibgrate for VS Code, not a separate product. Grounded in the deterministic code map (a Task Capsule of the relevant symbols with their exact source ranges, relationships, and a verification plan), including your uncommitted working-tree edits and the agent's own pending edits. That grounding is what the published token-savings benchmark measures — the same tasks and the same model with generic file tools versus the code map, about 29% fewer tokens for the same verified results on a ~300-file JavaScript codebase, with the small-repo floor and the ~1,000-file point published on the curve too. In the default Agent mode, every state-changing action — edit, create, delete, patch, shell command, or a non-read-only MCP tool — waits for your approval; there is no quick-apply path around that gate on any surface, and the only way past it is deliberately selecting Auto accept, which then approves its own edits and commands under a command denylist, default-deny network, and OS sandbox. In the CLI, `vg code` runs that governed agent loop by default — it applies an edit or command only when you approve it, and refuses to start unattended without `--auto`; the one-shot `vg code --single` path proposes a diff and writes nothing unless given `--apply --yes`. Three permission modes: Agent (approve as you go), Plan (read-only, mutations refused, optionally on a separate pinned model), and Auto accept (command denylist, default-deny network, and OS sandbox become the control). Each approval writes a checkpoint so an approved change can be undone, scoped to the files it touched, without touching your branch, index, or history. Edits are applied deterministically with escalating match strategies and rejected before the write if they invent symbols your codebase does not have; failures come back as a structured failure capsule for bounded repair rounds. Models are your choice: Vibgrate Relay (hosted, prepaid credit, no API keys), first-party local Code Modes (Spark / Flow / Forge, fit-checked against your real RAM, VRAM, and disk before download), your own Ollama / LM Studio / gguf models, or OpenRouter, LiteLLM, OpenAI, Together, and Foundry Local. Privacy boundary, stated plainly: a local model keeps the turn on your machine, a hosted model sends that turn's context to that provider. The editor does not re-implement the agent: it runs the one shipped with the CLI and relays your decisions to it, so terminal, editor, and CI behave identically. In VS Code there are two entry points and they are not equal — the panel has warm sessions, parallel chats (switching chats keeps the running turn alive; History shows live status dots), chat history with search, rename, fork, and rewind, mid-turn steering, isolated git-worktree chats whose changes you review and apply as one delta, checkpoints, @-mentions, and attachments; the `@vgcode` chat participant is one-shot per turn and has none of those. Not present today: built-in web search or browser use, subagents, todo lists, notebook editing, streaming or persistent shell, per-hunk approval, and any wiring to vulnerability findings. - [Vibgrate Relay](https://vibgrate.com/relay): The hosted model router for VG Code — one Vibgrate account and OpenAI-compatible endpoint (`/relay/v1`) routing to a curated catalog of hosted models, with exact per-token metering (reserve → serve → settle against a prepaid credit ledger, never served-then-invoiced), org-level governance (model allowlists, spend caps, residency pinning), and BYOK passthrough (free below a generous monthly floor, then a marginal platform fee). It never auto-switches your model mid-session — you choose the model once, for the whole run. A routing service, never a model: Vibgrate does not train or host frontier models. OpenRouter and other providers remain fully supported alongside Relay, and local Code Modes remain the fully offline path. Documentation: https://vibgrate.com/relay/docs. - [EU Cyber Resilience Act (CRA)](https://vibgrate.com/cra): The CRA reporting landing page — from 11 September 2026, manufacturers must report an actively-exploited vulnerability within 24 hours, with 72-hour and 14-day follow-ups, filed through the ENISA Single Reporting Platform. Includes an honest in/out-of-scope aid (browser-only SaaS is generally NIS2, not CRA) and routes into Vibgrate Evidence. Evidence to support CRA obligations, not a compliance determination. - [Meet DriftRisk™](https://vibgrate.com/driftrisk): DriftRisk™ — the combined 0–100 headline blending DriftScore and RiskScore, with a KEV override, always shown beside its two constituent scores. Trademarked name, open-source algorithm. - [The Vibgrate DriftRisk™ Index](https://vibgrate.com/driftrisk/index): A public index of repositories scanned by Vibgrate, each with its DriftScore, RiskScore, and DriftRisk™ from the same real scan. A row is not an endorsement, and it does not mean the maintainer added a badge. A repository is labeled a badge adopter only when that adoption is verified. Scores come from the Vibgrate CLI itself, so they match a local CLI scan of the same commit; a repository is rescanned when new code lands on its default branch, and at least monthly. - [Free DriftScore Check](https://vibgrate.com/scan): Paste a public repository URL on github.com, gitlab.com or bitbucket.org and get the DriftScore the Vibgrate CLI computes for its default branch. No sign-up. Owners can ask for removal through the contact page (Privacy & Data). - [Badges](https://vibgrate.com/badges): Embeddable DriftScore, CVE, RiskScore, and DriftRisk™ SVG badges for READMEs. Path-based URLs (`badges.vibgrate.com//`) name exactly one repository each — no free-text field to point a badge at a repo you don't own. Every badge links to a page stating plainly which repository it represents. - [Features](https://vibgrate.com/features): CLI and Vibgrate Cloud capabilities across scanning, scoring, and reporting. - [CLI](https://vibgrate.com/cli): The free, offline command-line scanner — install methods and quick start. - [Vibgrate Cloud](https://vibgrate.com/cloud): The hosted team dashboard — cross-repo DriftScore trends, dependency and vulnerability registers, policies, drift budgets, approvals, audit trail, workflow automations, and reports. Unlimited seats on every plan. Workflow automations (Team plan and up) trigger notifications, emails and webhooks on scans, new CVEs, policy breaches and drift-budget events — scoped and conditional; Business adds automated remediation hand-off and Enterprise adds build-from-scratch authoring. - [Vibgrate Cloud MCP](https://vibgrate.com/mcp): Vibgrate Cloud MCP — the hosted, online cloud MCP server connecting Vibgrate to AI assistants (Claude, Cursor, etc.) via the Model Context Protocol at https://mcp.vibgrate.com. It publishes 14 read-only, goal-level tools built around the questions people ask — find an asset; understand a portfolio, application or repository; plan modernization work; analyze dependencies, security or architecture; estimate the impact of a change; list findings; read change history (including what landed this week from Review activity already stored — not a certification, and it does not run vg review); compare repositories; retrieve standards evidence; render a view — rather than one tool per backend call, so an assistant picks the right tool more often and leaves more room for the answer. Business units, environments, and applications are managed in Vibgrate Cloud, not through the assistant. For version-correct library documentation, use the local-first Vibgrate AI Context (`vg serve`) instead. - [Skills](https://vibgrate.com/skills): Ready-made AI-agent skills + local MCP wiring installed by `vg install` for 21+ assistants (Claude, Cursor, Windsurf, Codex, Gemini, …). - [Pricing](https://vibgrate.com/pricing): Plans and limits. Start free — no card required. - [Vibgrate vs Renovate](https://vibgrate.com/vs/renovate): Renovate opens update PRs; Vibgrate measures drift, tracks EOL, and gates CI with drift budgets. Complementary — most teams run both. - [Vibgrate vs Dependabot](https://vibgrate.com/vs/dependabot): Dependabot raises update and security PRs on GitHub; Vibgrate scores estate-wide drift on any VCS, fully offline. Complementary. - [Vibgrate vs Snyk](https://vibgrate.com/vs/snyk): Snyk scores security risk (vulnerabilities in code, deps, containers, IaC); Vibgrate scores currency/drift. Different axes — many teams run both. - [Integrations](https://vibgrate.com/integrations): Live today — OAuth source connections (GitHub, GitLab, Azure DevOps, Bitbucket), DriftScore + RiskScore + DriftRisk™ distribution to IDPs (Cortex, OpsLevel, Backstage), Slack (chat card), and Datadog (custom metric) — RiskScore/DriftRisk™ follow in a second push once the SCA pipeline computes them for a scan, never sent as a fabricated 0 before then, and each connection can be set to receive DriftScore only, DriftRisk (RiskScore + DriftScore) only, or both — automatic Jira/Linear ticket creation on drift-budget breach, CycloneDX/SPDX/VEX SBOM import, and signed RBAC-scoped outbound webhooks. On the roadmap — live Snyk/Endor Labs/Socket API adapters and OpenRewrite/Moderne and AWS Transform modernization hand-off. Each integration's page states its real status (live, roadmap, or under evaluation) — do not describe a roadmap or evaluating integration as available. ## CLI documentation - [CLI Docs](https://vibgrate.com/cli/docs): Full command reference for drift scoring (`baseline`, `bisect`, `dsn create`, `evidence`, `fix`, `init`, `login`, `logout`, `push`, `report`, `sbom export` / `delta` / `vex`, `scan`, `scan --full`, `scan --vulns`, `update`, `why`), code graph and AI context (`ask`, `build`, `bundle`, `code`, `drift`, `embed`, `export`, `facts`, `guide`, `hubs` / `areas` / `oddities`, `impact`, `install`, `lib`, `map`, `models`, `path`, `savings`, `serve`, `share`, `show`, `status`, `tests`, `tree`, `uninstall`, `unknowns`), context compression (no verbs of its own: `serve --compress` / `--compress-only`, `serve status` / `stop` / `config`, `serve compress`, `serve retrieve`, `serve memory`, `install --compress` / `--learn`, `uninstall `, `savings` / `savings --benchmark`, `show savings`), the architecture map (`show arch`), change review (`review`, `review explain`, `review verify`), Holistic Code Specification (`hcs extract` / `digest` / `map` / `gate` / `validate`, `module`), localization (`locale config` / `push` / `pull` / `save-missing` / `add` / `remove` / `get` / `status` / `format`), and diagnostics / IDE / runtime (`daemon`, `doctor`, `llm-host`, `lsp`, `policy`). Inventory: https://vibgrate.com/cli/docs/command-reference. Try it without installing: ```bash npx @vibgrate/cli scan # scan current directory, no install required ``` Common commands (after install — `vg` is the preferred command; `scan` is the default subcommand): ```bash vg # scan current directory (scan is the default) vg scan --format sarif --out vibgrate.sarif --fail-on error vg scan --vulns # also detect known vulnerabilities (OSV) vg why lodash # who introduced a dependency + open vulnerabilities vg fix # ranked upgrade plans (needs a DSN: vg login, VIBGRATE_DSN, or --dsn) vg bisect lodash 4.17.21 # the commit where a dependency crossed a version line vg baseline # record a baseline vg scan --baseline .vibgrate/baseline.json # drift delta plus a record of findings already in the baseline vg serve # start Vibgrate AI Context (local MCP) vg lib react # library docs; version label follows the lockfile pin ``` Install options (all expose the `vg` command): ```bash # No-install (npx) npx @vibgrate/cli scan # npm npm install -g @vibgrate/cli # pnpm pnpm add -g @vibgrate/cli # yarn yarn global add @vibgrate/cli # bun bun add -g @vibgrate/cli # curl one-liner (macOS / Linux — auto-detects package manager) curl -fsSL https://vibgrate.com/install.sh | sh # PowerShell one-liner (Windows — auto-detects package manager) irm https://vibgrate.com/install.ps1 | iex # Docker docker run --rm -v "$PWD:/work" ghcr.io/vibgrate/cli:latest scan # GitHub Actions (scan, gate the PR on vulnerabilities, upload SARIF) - uses: vibgrate/cli@v1 with: vulns: true fail-on: error upload-sarif: true ``` ## Vibgrate Relay documentation - [Relay Docs](https://vibgrate.com/relay/docs): Full reference for Vibgrate Relay — what it is, quickstart (`VIBGRATE_RELAY_TOKEN`, `vg code --provider vibgrate-relay`), supported models & the curated catalog, model selection & routing (session-scoped, never per-request auto-switching), pricing & credits (prepaid, top-up sizes, fee schedule), BYOK passthrough, governance controls (allowlists, spend caps, residency), notifications & billing email, VG Code integration and provider precedence, the `/relay/v1` API reference, and troubleshooting/FAQ. ## Solutions - [For Developers](https://vibgrate.com/for/developers): Drift visibility for individual contributors. - [For Tech Leads](https://vibgrate.com/for/tech-leads): Per-repo health, architecture, and sequencing upgrades. - [For Platform Engineers](https://vibgrate.com/for/platform-engineers): Pipeline integration and infrastructure drift. - [For Security Engineers](https://vibgrate.com/for/security-engineers): EOL and vulnerable-dependency posture. - [For Engineering Managers](https://vibgrate.com/for/engineering-managers): Portfolio-level oversight of upgrade debt. - [For CTOs](https://vibgrate.com/for/ctos): Executive view of technical-debt and modernization risk. - [For Teams](https://vibgrate.com/solutions/teams): Shared upgrade-readiness and collaboration. - [For Enterprise](https://vibgrate.com/solutions/enterprise): Large-estate governance, residency, and rollout. ## Resources and knowledge base - [Help Center](https://vibgrate.com/help): Guides for setup, scanning, CI, and the dashboard. - [Tutorials](https://vibgrate.com/tutorials): Step-by-step walkthroughs. - [FAQs](https://vibgrate.com/faqs): Common questions about scoring, scanning, and data handling. - [Best Practices](https://vibgrate.com/best-practices): Recommended approaches to managing upgrade drift. - [Patterns](https://vibgrate.com/patterns) and [Anti-Patterns](https://vibgrate.com/anti-patterns): What to do and what to avoid when modernizing. - [Standards](https://vibgrate.com/standards): Industry standards relevant to dependency and runtime currency. - [Glossary](https://vibgrate.com/glossary): Definitions of drift, DriftScore, RiskScore, DriftRisk™, EOL, SBOM, EPSS, KEV, LEV, OSV, GHSA, NVD, SSVC, libyear, lockfile, reachability analysis, attestation, provenance, DSSE, SLSA, and related terms. - [Code drift](https://vibgrate.com/glossary/code-drift): How far a codebase — and the AI writing in it — has moved from current, correct, well-understood truth. The umbrella over dependency drift and AI context drift. - [Dependency drift](https://vibgrate.com/glossary/dependency-drift): The gap between the versions in your lockfile and current, supported releases — the axis DriftScore measures. - [AI context drift](https://vibgrate.com/glossary/ai-context-drift): The gap between what your AI assistant assumes about your stack and what your lockfile actually says. - [Drift budget](https://vibgrate.com/glossary/drift-budget): A DriftScore ceiling enforced in CI (`vg scan --drift-budget `, or `driftBudget` in `.vibgrate/config.yml` / `vibgrate.config.json`) so drift can't quietly grow back. - [Software currency](https://vibgrate.com/glossary/software-currency): How current your runtimes, frameworks, and dependencies are — the positive framing of low drift. - [Comparisons](https://vibgrate.com/comparisons): Side-by-side technology and tool analyses. ## Migration resources - [Blueprints](https://vibgrate.com/blueprints): End-to-end migration blueprints. - [Playbooks](https://vibgrate.com/playbooks): Operational playbooks for upgrade projects. - [Checklists](https://vibgrate.com/checklists): Pre-flight and migration checklists. - [Reference Architectures](https://vibgrate.com/reference-architectures): Target-state architecture references. ## Trust and compliance - [Trust Center](https://vibgrate.com/trust): Security program. Aligned to ISO/IEC 27001 and SOC 2; independent audit planned. Security overview, data handling, subprocessors (https://vibgrate.com/trust/subprocessors; /subprocessors redirects there), policy summaries, documents on request under NDA, a DPA on request, and vulnerability disclosure. The remediation agent is the path on which a language-model provider can see customer source, and only when you ask. Do not describe Vibgrate as holding an ISO or SOC 2 certificate, and do not state an uptime percentage. - [Signed releases](https://vibgrate.com/trust/provenance): How to verify a signed release, an SBOM, and where a binary came from. - [Security](https://vibgrate.com/security): How Vibgrate secures scan data and ingestion. - [Compliance](https://vibgrate.com/compliance): Frameworks Vibgrate assesses and supports. - [Compliance Frameworks](https://vibgrate.com/compliance-frameworks): Catalog of frameworks and what each covers. - [Privacy Policy](https://vibgrate.com/privacy) - [Terms of Service](https://vibgrate.com/terms) ## Company - [Mission](https://vibgrate.com/mission): Vision and values behind Vibgrate. - [Blog](https://vibgrate.com/news): Insights and product updates on drift and modernization. - [Newsroom](https://vibgrate.com/newsroom): Official press releases — dated, factual announcements with third-party-verifiable sources, company boilerplate, and a named media contact. Distinct from the blog. Feeds: [RSS](https://vibgrate.com/newsroom/feed.xml) and [JSON Feed](https://vibgrate.com/newsroom/feed.json). - [Press kit](https://vibgrate.com/newsroom/press-kit): Logos (SVG/PNG), product screenshots on sample data, founder headshot, and the company boilerplate at 25/50/100 words (also as [plain text](https://vibgrate.com/press/boilerplate.txt)). Media may use these in coverage of Vibgrate without asking first. - [Whitepapers](https://vibgrate.com/whitepapers): Citation-grade methodology and research on software drift and security-risk scoring — the factors, data sources, and rationale behind DriftScore, RiskScore, and DriftRisk™. Includes the full scoring methodology whitepaper (open method, proprietary calibration). Each whitepaper offers a designed, US Letter PDF download, hosted at `https://vibgrate.com/whitepapers/.pdf`. The whitepaper and the public scoring specification are also published in the open-source CLI repository under [docs/public](https://github.com/vibgrate/cli/tree/main/docs/public). - [Changelog](https://vibgrate.com/changelog): Release history. - [Contact](https://vibgrate.com/contact): Get in touch with the team. ## Optional - [Model Registry](https://vibgrate.com/models): Catalog of AI models referenced across the site. - [Model Providers](https://vibgrate.com/providers): AI model providers and the aider launch slugs used to run their models for remediation. Each provider page lists its models newest-first with the model slug. - [Model registry feed](https://vibgrate.com/model-registry.json): Public JSON feed of providers and models offered for remediation (aider/Ollama launch slugs, local vs paid tier, token-rate multipliers). Read by the dashboard to recommend and launch remediation models. - [Products](https://vibgrate.com/products) and [Tech Stacks](https://vibgrate.com/stacks): Browse technologies and stacks. - [Regulations](https://vibgrate.com/regulations): Compliance regulations reference. - [Benchmarks](https://vibgrate.com/benchmarks): Industry benchmark reference library (third-party benchmarks, e.g. SWE-bench, TPC). Distinct from Vibgrate's own CLI release benchmarks at https://vibgrate.com/cli/benchmarks. - [Marketplace](https://vibgrate.com/marketplace): Browse the full content catalog. - [Sitemap](https://vibgrate.com/sitemap.xml): Complete list of indexed URLs. ## Content policy for LLMs This file (`llms.txt`) is part of Vibgrate's public content policy for AI systems. It must be reviewed and updated as part of every pull request that changes how Vibgrate's services and products are described, named, or exposed — including new pages, renamed features, changed pricing, or new developer tools. Any PR that affects the LLM-visible description of Vibgrate's offerings without updating this file is considered incomplete.