Sibling contract

Monitor

Monitor is the continuous-governance layer: re-score a URL on a cadence, store snapshots, compute drift deltas against the baseline, and surface regressions before they compound. Every prior designesy surface is a snapshot — monitor turns them into a watched series.

Version 0.1.0 · provisional · machine export

Source authority

Primary source

Designesy design intelligence research 2026-08-01

Temporal gap

Into Design Systems 2026 — "weekly audits at cents per report, drift detection without dedicated headcount"

Drift shape

Design Systems Collective 2026 (Enara) — "the system surfaces the shape of how drift happens, the only way to stop it before it compounds"

Compounding

Lollylop 2026 — "visual bugs are invisible to code reviews, every sprint adds a little more, drift catches it before it compounds"

Competitor lane

Designesy 2026 scan — no competitor combines URL-scoped production fetch + design-token-aware checks + scheduled cadence + trend-over-time

Monitoring model

How it works

Register a URL + cadence (daily/weekly/monthly). On each run, re-execute the 12 drift checks (d01-d12) and store a snapshot. Compute deltas against the first-run 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

01urlThe watched URL

02timestampISO 8601 run timestamp

03score0-100 drift score at this run

04gradeA-F letter grade

05checksArray of 12 CheckResult objects (d01-d12)

06tokensExtractedNumber of :root custom properties found

Cadence options

01dailyRe-scan every 24 hours — for active redesigns

02weeklyRe-scan every 7 days — the industry default ("weekly audits")

03monthlyRe-scan every 30 days — for stable production sites

Alert triggers

01score degradationScore dropped > N points since the previous run (default threshold: 5)

02new violationA check that was PASS/WARN in the previous run is now FAIL

03token mutationTokens added, removed, or renamed since the baseline (silent breaking changes — drift mode 4)

04grade dropLetter grade fell (e.g. A → B) since the previous run

Verification

10 checks — 10 checks. PASS=1, WARN=0.5, FAIL=0. Score = (points/10) × 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), not design quality — design quality is the /score surface.

01m01 · Schedule registered — URL + cadence recordedPASS: Monitor registered with cadence and alert target · FAIL: No monitor registered — the URL is not being watched

02m02 · Last run fresh — ran within the cadence windowPASS: Last run is within the cadence window · FAIL: Last run is stale — the monitor may have stopped · WARN: Last run is near the edge of the cadence window

03m03 · Drift delta vs baseline — score change since first runPASS: Score is stable or improved vs baseline · FAIL: Score degraded significantly vs baseline · WARN: Score slipped slightly vs baseline

04m04 · Drift trend slope — 3-run trajectoryPASS: Trend is flat or improving over the last 3 runs · FAIL: Trend is regressing over the last 3 runs · WARN: Trend is flat but score is low

05m05 · New violations since last run — checks that newly failPASS: No new violations since the previous run · FAIL: N checks newly failed since the previous run · WARN: 1 check newly warned since the previous run

06m06 · Resolved since last run — checks that newly passPASS: N checks newly passed since the previous run — the system is healing · FAIL: No checks resolved since the previous run · WARN: 1 check improved from FAIL to WARN

07m07 · Score degradation threshold — alert if score drops > N pointsPASS: Score drop within threshold since previous run · FAIL: Score dropped beyond the alert threshold — alert fired

08m08 · Token-set mutation — tokens added/removed/renamed since baselinePASS: Token set is stable vs baseline · FAIL: Token set mutated — tokens added, removed, or renamed (silent breaking changes) · WARN: 1-2 token changes since baseline

09m09 · Contract version drift — the site own DTCG/agent.json changed since last runPASS: No contract version change detected · FAIL: Contract version changed since last run — verify the change is intentional · WARN: Contract metadata changed (not version)

10m10 · Alert delivered — email fired on threshold breachPASS: Alert delivered to the registered email address via Resend · FAIL: Alert could not be delivered — check the email address or RESEND_API_KEY · WARN: Alert surfaced in-UI only — no email provided or Resend key not set

Validation: Designesy monitor engine — scheduled re-scan + snapshot storage + delta computation. Method: Re-run the 12 drift checks on cadence, store snapshots, compute deltas vs baseline and previous run, fire alerts on threshold breach. Browser-only checks: None — all checks are static CSS analysis + snapshot diffing, no browser needed.

Open questions

Snapshot storage is client-side (localStorage) in v0.1.0 — production monitoring needs server-side persistence (database or KV store)
Email alerting (m10) requires RESEND_API_KEY env var + verified sending domain (monitor@designesy.org) — without the key, alerts surface in-UI only
Scheduled cadence (daily/weekly/monthly) requires a cron runner (Vercel Cron Jobs) — v0.1.0 monitors on manual trigger only
Cross-page drift (drift mode 2) requires crawling multiple pages — the monitor currently watches the single registered URL
The 3-run trend slope (m04) needs 3 snapshots — the first 2 runs will show insufficient data
Contract version drift (m09) probes for agent.json version field — not all sites expose one

Run it

Monitor any URL for drift over time:

Monitor a URL →API endpoint

The monitor contract is the continuous-governance layer — it turns every prior designesy surface from a snapshot into a watched series.Machine export.