The ten commitments
1. We never send your data anywhere without explicit opt-in
1. We never send your data anywhere without explicit opt-in
Charter runs entirely offline. The scanner reads your repo, computes a score, and writes output to your terminal or a file — no network calls, no telemetry, no usage pings. Charter works in airgapped environments by design.The alternative was a hosted scoring API that could enrich findings with cross-repo signals. But that would require you to trust us with source code you haven’t consented to share. We chose local execution instead. The tradeoff is that we can’t offer SaaS-style dashboards without a separate, explicit opt-in integration — and we think that’s the right tradeoff.
2. We never call an LLM
2. We never call an LLM
Every finding Charter produces comes from deterministic static analysis. No model inference, no embedding lookups, no generative explanations at scan time. Same repo plus same version equals same score. Every time.The alternative — using an LLM to generate richer fix suggestions or natural-language explanations — would introduce non-determinism and require an API key you may not want to provide. Determinism makes scores comparable across runs, auditable in CI, and trustworthy as a policy gate. A gate that gives different answers on different days is not a gate you can rely on.
3. We never delete a user file
3. We never delete a user file
Charter’s fix engine creates, appends, and replaces files. It does not delete, rename, or move files outside of
.charter/backups/. The original is always preserved before any write.The alternative — overwriting in place without backup — is faster but unrecoverable if a fixer has a bug. We chose the slower path that leaves you in control. The backup directory accumulates until you decide to clear it; Charter never does it for you.4. We never apply a fix without showing a diff first
4. We never apply a fix without showing a diff first
Running
charter fix without --dry-run still computes and displays a unified diff before writing anything. You must see the change before it lands. Always.The alternative was a one-shot apply that minimizes output noise. We rejected it because a fixer that modifies files without a visible checkpoint is indistinguishable from a bug. The diff is not a UI nicety — it is the last human checkpoint between Charter’s judgment and your codebase.5. Every finding includes a rule ID, evidence, and a fix suggestion
5. Every finding includes a rule ID, evidence, and a fix suggestion
Findings are not just scores. Each one names the rule that fired, identifies or quotes the specific evidence in your repo (redacted if it contains a secret), and tells you what a passing state looks like.The alternative — reporting only a summary score — is easier to implement but gives you nothing actionable. Terse output optimizes for dashboards; Charter optimizes for the engineer who has to fix the problem. Vague findings are useless; specific findings with a path forward are the product.
6. Every release is signed (SLSA L3 + cosign keyless)
6. Every release is signed (SLSA L3 + cosign keyless)
Release artifacts are signed using cosign keyless signing. SLSA Level 3 provenance is attached to every build. SPDX 2.3 SBOMs are published alongside binaries.Charter enforces supply-chain integrity on others. It holds itself to the same standard. The alternative — shipping unsigned tarballs — is the open-source default, but a tool that modifies your repo and runs in CI has elevated supply-chain risk. We chose the higher standard even though it adds build complexity. You can verify any Charter release against its provenance without trusting us to say it’s clean.
7. The score formula is public and stable within a major version
7. The score formula is public and stable within a major version
The formula
max(0, 100 − B×20 − H×10 − M×4 − L×1) with its hard caps is documented, fixed within a major version, and will not change in a patch release.Teams gate CI on this number. Surprise changes would break real pipelines. The alternative — a proprietary model that improves continuously — would make scores non-comparable across time and undermine any policy threshold you’ve set. Stability is a feature, not a limitation. A major-version upgrade is the only place where the formula can change, and when it does, we document exactly why.8. Charter is cross-vendor
8. Charter is cross-vendor
Charter checks for agent config patterns across Claude Code, Cursor, GitHub Copilot, Gemini CLI, Windsurf, OpenCode, and Aider — without preferring any one. The score means the same thing regardless of which coding agent your team uses.The alternative — optimizing for a single vendor’s conventions — would make Charter a vendor-specific linter rather than a neutral readiness standard. Agent tooling is still consolidating. A repo’s readiness score should not depend on which model happens to be popular this quarter.
9. We never print raw secret values in any output
9. We never print raw secret values in any output
When Charter detects a credential or token in your repo, it reports the file path, line number, and rule ID. Never the secret value itself. Evidence is redacted: the first 4 characters are shown; the rest is replaced with
…. This holds in terminal output, JSON, SARIF, Markdown, and the HTML report.The alternative — showing the matched string so you can identify it — risks the secret appearing in CI logs, terminal recordings, or bug reports. You already know what the secret is; you need to know where it is. Charter gives you the location, not the value.10. The CLI is free forever
10. The CLI is free forever
Charter’s core CLI will never be paywalled. No freemium gate on the command-line scan. No expiring trial. The score is only useful as a community standard if everyone can reproduce it.Paid offerings, if they exist, will be integrations layered on top of the open core — multi-repo dashboards, policy enforcement, managed CI — not restrictions on the core tool itself. The CLI stays Apache-2.0 and free, always.