Skip to main content
interlace
Getting startedConcepts

Transparency Dashboard

The dimensions Interlace measures itself on — peer health, CVE-to-rule latency, API-surface coverage, per-rule p95 budgets, and resource profile — and where to find the live data.

Why this page exists

The lint-tier ecosystem is full of plugins that publish a few headline numbers. Interlace publishes the measurement system — every dimension we evaluate ourselves on, every dimension we evaluate peers on, and the raw artifact behind every claim. If a row on this page links to a JSON file, that JSON is the source of truth; the prose summary on the page is rendered from it.

Every measurement on this page reduces to a row in distribution/EVALUATION_METRICS.md. If a marketing claim about Interlace can't reduce to one of those rows, it's a feeling, not a measurement, and it shouldn't ship.


What we measure — at a glance

CVE → rule latency

Days between a public CVE disclosure (in a covered library / framework) and the Interlace rule that detects the underlying pattern shipping. Target: ≤ 14 days for live-feed entries.

API-surface coverage

Per domain-security plugin: % of the target SDK / runtime callable surface with at least one rule covering misuse. Floor: 60% per plugin.

Per-rule p95 budget

Per-rule p50 / p95 latency budgets, CI-enforced. Rules exceeding budget × (1 + tolerance) or the 1000 ms hard ceiling fail the build.

Resource profile

Peak RSS + cold-start per engine + preset on a fixed corpus. CI memory budget: 80% of 7 GB runner = ~5.6 GB.

Peer health snapshot

Weekly snapshot of every ESLint-plugin neighbor in our landscape — npm downloads, release cadence, days since release, GitHub stars, open issues, 90-day contributors.

Headline scorecard

Aggregate scorecard weighted across correctness, coverage, performance, engine portability, AI-readiness, DX, determinism, compatibility.


Live artifacts

Each row links to the live JSON + rendered markdown view in the repo. They're regenerated by the named script and committed; the GitHub workflow column lists what triggers the refresh.

DimensionLive dataGenerated byTrigger
CVE → rule latencycve-rule-latency.json · .mdaudit-cve-rule-latency.tsPR-touch of the log or any security plugin + nightly cron
API-surface coverageapi-surface-manifest.json · .mdaudit-api-surface.tsPR-touch of any security plugin or the manifest
Per-rule p95 budgetper-rule-p95.json · .mdcheck-per-rule-budget.tsPR-touch of the budget or new flagship results
Resource profileresource-profile.json · .mdilb-resource-profile.tsManual / scheduled
Peer health snapshotpeer-health.json · .mdfetch-peer-health.tsWeekly Monday cron, auto-commit
Headline scorecardscorecard.mdilb-scorecard.tsManual / scheduled
CWE coveragecwe-coverage.md · -gaps.mdnpm run ilb:cweManual / scheduled
ISO 25010 crosswalkiso25010-crosswalk.mdnpm run ilb:iso25010Manual / scheduled
Compliance crosswalk (NIST SSDF / OWASP ASVS / CAPEC)compliance-crosswalk.mdnpm run ilb:complianceManual / scheduled

How a claim becomes a measurement

Every public Interlace claim follows the same path:

  1. The dimension is named in EVALUATION_METRICS.md — its operational definition, unit, target, and peer-comparability.
  2. A script under scripts/ produces a dated JSON artifact under benchmark-results/ or benchmarks/results/.
  3. A GitHub workflow under .github/workflows/ runs the script on PR or on schedule.
  4. The claim is registered in CLAIMS.md with the artifact and last-verified date.
  5. Marketing text on docs / homepage / READMEs links back to the claim row.

If any link in that chain breaks, the claim is stale and gets a "verification pending" banner in docs until refreshed. We treat this like a build failure.


What we deliberately don't measure (yet)

Honest deferrals — each is named in EVALUATION_METRICS.md and tracked in the gap-closure history.

  • Per-call latency distribution. Today the per-rule budget gate normalizes total corpus time by file count. Real per-call p50 / p95 needs the bench runner to wrap each rule's visitor; that's planned for the next ilb-flagship schema bump.
  • Time-to-first-response for peer plugin issues. §9 placeholder in EVALUATION_METRICS.md. Requires paginating gh api repos/<owner>/<repo>/issues with rate-limit handling.
  • Adversarial-rewrite resilience numbers for SAST tools. We measure ours (ilb-evade); we don't run CodeQL / Semgrep / Snyk through the same corpus.

When a deferral closes, the row in EVALUATION_METRICS.md gets the artifact pointer and this list shrinks.


Building secure JavaScript with Interlace? Star the repo to get new rules and CWE coverage as we ship them — or follow the AI-code-security benchmarks behind them.