designesy
Score a site

Sibling contract

Monitor

Monitor is the governance layer over time: each call re-runs the drift checks on a URL and compares the result with the history the caller passes in, computing deltas against the first snapshot (the baseline) and the one before, so a regression shows on the run it lands. Nothing is scheduled, and the server keeps no history of its own (each result is cached for 24 hours); /monitor keeps the history in your browser.

Version 0.1.3 · provisional · machine export

View as Markdown

Source authority

Temporal gap
Weekly audits at cents per report. Drift detection without dedicated headcount.
Into Design Systems 2026
Drift shape
It surfaces the shape of how drift happens, which is the only way to stop it before it compounds.
Cristian Morales Achiardi, Design Systems Collective 2026
Competitor lane
URL-scoped production fetch + design-token-aware checks + trend over the history the caller supplies
Primary source
Designesy design intelligence research 2026-08-01

Monitoring model

How it works

Each call re-executes the 12 drift checks (d01-d12) on the URL and returns a snapshot; the caller keeps it and passes the earlier snapshots back as history on the next call. Deltas are computed against the first snapshot in that history (the baseline): score delta, new violations, resolved violations, token-set mutations, and trend slope across the last 3 runs. Alert when score degrades beyond a threshold or when new violations appear.

Snapshot structure

01 url The watched URL string
02 timestamp ISO 8601 run timestamp string
03 score 0-100 drift score at this run number
04 grade A-F letter grade string
05 checks Array of 12 CheckResult objects (d01-d12) CheckResult[]
06 tokensExtracted Number of :root custom properties found number

Cadence options (planned)

Nothing runs on a schedule today: version 0.1.3 runs when it is called, on the history the caller passes in. These are the cadences the contract defines for a scheduler.

01 daily Re-scan every 24 hours: for active redesigns 24h
02 weekly Re-scan every 7 days: the industry default ("weekly audits") 7d
03 monthly Re-scan every 30 days: for stable production sites 30d

Alert triggers

01 score degradation Score dropped > N points since the previous run (default threshold: 5) drop > 5 points vs previous run
02 new violation A check that was PASS/WARN in the previous run is now FAIL PASS/WARN → FAIL vs previous run
03 token mutation Tokens added, removed, or renamed since the baseline (silent breaking changes: drift mode 4) added · removed · renamed vs baseline
04 grade drop Letter grade fell (e.g. A → B) since the previous run e.g. A → B vs previous run

Verification

10 checks. PASS=1, WARN=0.5, FAIL=0; SKIP (m01 and m02 on a first run) is not scored. Score = (points / scored checks) × 100. A≥90, B≥80, C≥70, D≥60, F<60. Note: the monitor score reflects governance health (is the watch working, is the site stable) rather than design quality, which is the /score surface.

01 m01 · History supplied: the request carries earlier runs to compare against (nothing is scheduled or stored server-side) Pass At least one earlier run supplied Fail n/a N/A No history: drift needs a previous run; a first run sets the baseline and is not scored here
02 m02 · Last run fresh: the newest supplied run is within the cadence window (the request names daily, weekly or monthly; weekly by default) Pass Newest run is within one cadence window Warn Newest run is between one and two cadence windows old (a run was missed) Fail Newest run is more than two cadence windows old (the watch may have stopped) N/A No history, or no usable timestamp on the newest run: nothing to measure the gap from
03 m03 · Drift delta vs baseline: score change since first run Pass Score is stable or improved vs baseline Warn Score slipped slightly vs baseline Fail Score degraded significantly vs baseline
04 m04 · Drift trend slope: 3-run trajectory Pass Trend is flat or improving over the last 3 runs Warn Trend is flat but score is low Fail Trend is regressing over the last 3 runs
05 m05 · New violations since last run: checks that newly fail Pass No new violations since the previous run Warn 1 check newly warned since the previous run Fail N checks newly failed since the previous run
06 m06 · Resolved since last run: checks that newly pass Pass N checks newly passed since the previous run (the system is healing) Warn 1 check improved from FAIL to WARN Fail No checks resolved since the previous run
07 m07 · Score degradation threshold: alert if score drops > N points Pass Score drop within threshold since previous run Fail Score dropped beyond the alert threshold (alert fired)
08 m08 · Token-set mutation: tokens added/removed/renamed since baseline Pass Token set is stable vs baseline Warn 1-2 token changes since baseline Fail Token set mutated; tokens added, removed, or renamed (silent breaking changes)
09 m09 · Contract version drift: the design contract version this run is scored against (the version designesy_score reports) changed since last run Pass No contract version change detected Warn Contract metadata changed (not version) Fail Contract version changed since last run (verify the change is intentional)
10 m10 · Alert delivered: email fired on threshold breach Pass Alert delivered to the registered email address via Resend Warn Alert surfaced in-UI only (no email provided or Resend key not set) Fail Alert could not be delivered (check the email address or RESEND_API_KEY)

Validation

Designesy monitor engine: on-demand re-scan + caller-supplied history + delta computation. Method: Re-run the 12 drift checks on each call, compute deltas vs the baseline and the previous run in the history passed in, fire alerts on threshold breach. Browser-only checks: None: all checks are static CSS analysis + snapshot diffing, no browser needed.

Open questions

Run it

Monitor any URL for drift over time:

Monitor a URL →API endpoint
The monitor contract is the governance layer over time: each call compares a URL with the history you pass in. Machine export.