How Clamper works

Three install surfaces. One policy engine. Every gate decision answers four questions: What violations exist? Which are new vs pre-existing? What does the policy say to do about each class? Is the deploy blocked, warned, or permitted — and is the audit record signed?

The pipeline

PR / push / Vercel deploy
   |
   v
TRIGGER -> SCAN -> FINGERPRINT -> BASELINE-DIFF -> POLICY-EVAL -> GATE -> AUDIT
   |         |          |             |              |          |       |
   |         |          |             |              |          |       +-> hash-chained signed record
   |         |          |             |              |          +-> pass / fail / warn
   |         |          |             |              +-> enforcement rules per recency
   |         |          |             +-> new / pre-existing / resolved
   |         |          +-> SHA-256(rule, selector, file, severity)
   |         +-> axe-core / privacy / security ingest
   +-> GH Actions / Vercel Checks API / CLI

Where Clamper sits

Clamper does not re-implement the scanners. It consumes findings from upstream Ariada engines and applies the policy gate at Layer 5. The same eight-layer architecture shows up on every site in the family; on this page Layer 5 is highlighted.

  1. Governance & dashboards ariada.ai
  2. Visualization & comms draculascan
  3. CI/CD compliance gate clamper.ai
  4. Remediation reverter.ai
  5. Authorship attribution blamer.ai
  6. Cross-domain mapping shared core
  7. Single-pass DOM iteration ariada engine
  8. Platform AX tree + axe-core shared core
Clamper operates at Layer 5 (the gate). Findings flow up from Layers 0–3; gate decisions flow out to Layer 7 (governance) and audit storage.

Three install surfaces

1. GitHub Action

Two-minute YAML snippet in .github/workflows/clamper.yml. On every PR, Clamper scans the changed files, fingerprints findings, queries the per-branch baseline, evaluates the policy, and posts an inline review comment per finding plus a summary comment. 

# .github/workflows/clamper.yml
name: Clamper Gate
on:
  pull_request:
    branches: [main]
jobs:
  gate:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      checks: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0   # baseline-diff needs history
      - uses: ariada-ai/clamper@v1
        with:
          policy-file: .clamper.yml
          domains: a11y,privacy,security
          baseline-mode: both
          comment-mode: both
  • Exit codes: 0 pass, 1 fail (blocked), 2 warn, 3 invalid policy, 4 scan error
  • Single bundled dist/index.js (no npm install in customer pipelines)
  • Free for OSS public repos; private repos count toward the tier’s monthly build limit

2. Vercel Marketplace App

One-click install from Vercel Marketplace. Each preview deploy emits a deployment.ready webhook; Clamper scans the preview URL and posts a Vercel Checks API entry. A failing check blocks promotion to production when configured.

  • Targets the Vercel deploy — not the source repo — so it works for any framework that ships a Vercel preview
  • Same policy file (.clamper.yml) as the GitHub Action
  • Phase 1 launch surface (along with GitHub Marketplace)

3. CLI Tool

Run locally, in pre-commit, or in any non-GitHub CI pipeline: 

npx @clamper/cli scan ./dist
npx @clamper/cli scan https://staging.example.com
  • Outputs human-readable terminal report, JSON, or SARIF 2.1.0
  • Reads the same .clamper.yml policy file
  • Use case: GitLab CI, Bitbucket Pipelines, CircleCI, Jenkins (Phase 2 native plugins planned)

The .clamper.yml policy file

Single declarative configuration at the repo root. Validated against a public JSON Schema. Cascades from an org-level default down through team, repo, branch, and environment overrides — child policies can add rules or tighten thresholds, but cannot relax a parent rule. 

version: 1
extends: org-default              # Pro+ tier feature
domains:
  a11y:
    standard: WCAG_2_1_AA
    engine: axe-core@4.11
    enforcement:
      - when: { recency: new, severity: [critical, serious] }
        action: block
      - when: { recency: new, severity: moderate }
        action: warn
      - when: { recency: pre_existing }
        action: pass               # baseline tolerance
      - when: { recency: resolved }
        action: celebrate
  privacy:
    enforcement:
      - when: { rule_id: pii_in_dom, recency: new }
        action: block
exemptions:
  registry: .clamper/exemptions.yml
audit:
  hash_chain: true
  signing_key: clamper-managed

Baseline engine

Every finding has a deterministic fingerprint: 

SHA-256(rule_id || normalized_selector || normalized_source_file || severity)

Eight compliance domains

MVP ships three domains active by default (a11y, privacy, security ingest). The remaining domains layer in by tier and phase.

Domain Detection engine Default in MVP?
Web accessibility (WCAG / EAA / EN 301 549) axe-core 4.11 + Pa11y + custom rules Yes (primary)
Privacy (GDPR / CCPA / cookie / PII) Custom regex + DOM heuristics Yes (configurable)
Security (SAST / OWASP) Pluggable upstream (Semgrep / CodeQL output) Yes (read-only ingest)
AI regulatory (EU AI Act Art. 50) Pluggable Phase 2
Code quality (lint / complexity) Pluggable (ESLint / SonarQube output) Phase 2
API specification (OpenAPI conformance) Pluggable (Spectral output) Phase 3
Performance (Core Web Vitals) Lighthouse Phase 2
Sustainability (WSG / carbon) Pluggable (Web Sustainability Guidelines subset) Phase 3

Hash-chained signed audit record

Every gate decision emits a canonical JSON record (RFC 8785 JCS), Ed25519-signed, with a SHA-256 hash chain to the previous record: 

H_n = SHA-256(H_{n-1} || canonical_record_n)

Validation evidence (honest framing)

End-to-end Clamper gate accuracy on production customer pipelines is pending pilot data. We do not claim "100% precision on customer codebases" until we publish a per-customer report. What we have validated to date:

See pricing →