Skip to main content
VectorLint gives you two complementary levers for controlling review precision. Used together, they let you calibrate how aggressively VectorLint surfaces findings across your project.
  • CONFIDENCE_THRESHOLD: controls how strictly raw model candidates are filtered before surfacing them. A global setting that applies to every review.
  • Strictness: controls how strongly check rules penalize errors when scoring. Set per rule in frontmatter; see Strictness.
Understanding when to reach for each one is the key to a low-noise, high-signal workflow.

​
How the two levers differ

CONFIDENCE_THRESHOLD operates at the filtering stage. It determines whether a candidate violation gets surfaced at all. Lower it and more candidates pass through. Raise it and only the highest-confidence findings appear. Strictness operates at the scoring stage. It determines how heavily a violation is penalized once it’s already been surfaced. Higher strictness means a given error density produces a lower score and triggers violations more readily. They’re solving different problems. CONFIDENCE_THRESHOLD reduces noise from the model’s judgment. Strictness controls how demanding your quality bar is for a given rule.

​
When to tune CONFIDENCE_THRESHOLD

The default of 0.75 is a reasonable starting point. Adjust it when the balance between findings and noise isn’t working for your team. 
CONFIDENCE_THRESHOLD=0.75
ValueEffectWhen to use
Lower (e.g. 0.5)More findings, higher recall, more noiseEarly-stage rule development, finding gaps in coverage
Default (0.75)Balanced precision and recallMost production workflows
Higher (e.g. 0.9)Fewer findings, higher precision, less noiseCI gates, customer-facing content, high-trust workflows
Set this in ~/.vectorlint/config.toml for a global default, or in a project .env file to override it for a specific project.
When writing a new rule, temporarily lower CONFIDENCE_THRESHOLD to see everything the model flags. Once you’ve validated the rule’s coverage, raise it back to filter out low-confidence candidates.

​
Tuning for CI environments

In CI, false positives block merges. A finding that a writer might reasonably dismiss becomes a pipeline failure that needs explaining. Two adjustments help: Raise CONFIDENCE_THRESHOLD in CI. Set it higher in your CI environment’s .env than in local development. This means only the highest-confidence findings block a merge. Lower-confidence candidates still get caught locally where a writer can review them in context. 
# .env in CI environment
CONFIDENCE_THRESHOLD=0.85
Use strict patterns only on production-bound content. Gate CI checks on the directories that actually ship, not on drafts or work-in-progress: 
# Only these files block CI
[content/docs/**/*.md]
RunRules=TechDocs

# These files are checked locally but don't gate CI
[content/drafts/**/*.md]
RunRules=

​
A practical starting point for teams

If you’re rolling VectorLint out across a team for the first time, start permissive and tighten over time. A workflow that generates too many findings on day one loses the team’s trust before it earns it.
  1. Start with CONFIDENCE_THRESHOLD=0.75 and standard strictness
  2. Run against your existing content library and review the findings as a team
  3. Raise strictness on your highest-stakes rules first
  4. Raise CONFIDENCE_THRESHOLD once your rules are stable and reviewed

​
Next steps