Audit trigger matrix

Which quality pillars run for each user action, API call, or CI job — VisualQ's 8-pillar model.

VisualQ organizes web quality into 8 pillars. This page documents which pillars actually execute for each dashboard button, API endpoint, or scheduled job — not just what appears in the composite score.

All heavy audits run on the Playwright worker (worker.visualq.ai). The Next.js app orchestrates dispatch, Firestore callbacks, and score persistence.

The 8 pillars

#	Pillar	Technical id	Audit unit	Primary trigger
1	Visual	`visual`	VRT page (`scenarios/`)	Run VRT, baseline
2	Accessibility	`a11y`	VRT page	A11y button or VRT piggyback
3	Performance	`perf`	VRT page	Perf button or VRT piggyback
4	SEO	`seo`	VRT page	SEO button or VRT piggyback
5	Security	`security`	VRT page	Security button or VRT piggyback
6	Tracking	`tracking`	Tracking plan → linked VRT + FRT	Tracking / Analytics button
7	Privacy	`privacy`	VRT page (triple-run)	Privacy button or full audit
8	Functional (FRT)	`functional`	FRT journey (`features/`)	Run feature / FRT batch

The Functional pillar maps to the FRT module in the UI. An FRT journey is never triggered from a VRT page alone — that is a product constraint, not an exclusion from the quality score.

Trigger matrix

Read across: columns show pillars executed and persisted when the user (or CI) launches the row trigger.

Trigger	Visual	A11y	Perf	SEO	Security	Tracking	Privacy	FRT	Scenarios in scope	Browser sessions (order of magnitude)
Run VRT	✅	✅	✅	✅	✅	—	—	—	Selected or all VRT scenarios	1 / page (shared capture)
Run A11y only	—	✅	—	—	—	—	—	—	Selected or all VRT scenarios	1 / page
Run Perf only	—	—	✅	—	—	—	—	—	Selected or all VRT scenarios	1 / page
Run SEO only	—	—	—	✅	—	—	—	—	Selected or all VRT scenarios	1 / page
Run Security only	—	—	—	—	✅	—	—	—	Selected or all VRT scenarios	1 / page
Run Privacy only	—	—	—	—	—	—	✅	—	Selected or all VRT scenarios	3 / page (initial, reject, accept)
Run FRT (feature / batch)	—	—	—	—	—	—	—	✅	Selected FRT features	1 / FRT scenario
Run Tracking	—	—	—	—	—	✅	—	✅*	Tracking plan: linked VRT pages + linked FRT features	1 / linked page + 1 / linked FRT scenario
Full audit (8 pillars)	✅	✅	✅	✅	✅	✅	✅	✅	All VRT + all FRT features + tracking plan	Page batch + privacy triple-run + FRT batch + tracking fan-out

Legend

Symbol	Meaning
✅	Pillar runs; results persist to quality score and/or rolling health (`page_health`, `frt_health`, tracking plan).
—	Pillar not executed for this trigger.
✅*	FRT runs only for features linked to tracking-plan events — not the entire project FRT suite.

Per-trigger behavior

Run VRT (page piggyback)

Run VRT dispatches an audit-batch with page pillars: visual, a11y, perf, seo, security. The worker performs one navigation per VRT scenario and runs screenshot, axe, perf probes, SEO audit, and security audit on the already-loaded page.

Overhead vs VRT-only is small: probes run during capture without an extra reload. Tracking and FRT are not included in this click.

Single page pillar

A11y, Perf, SEO, Security, or Privacy buttons (or /api/tests/a11y, /api/tests/privacy, etc.) dispatch a dedicated runType. Only that probe runs — no VRT screenshot, no other pillars.

Run Privacy (triple-run)

Privacy dispatches privacy-test. Each VRT scenario runs three isolated browser contexts: initial load, reject-all, accept-all. Cookies, network hits, storage, CMP banner, policy link, and optional TCF/GCM signals are captured per stage. This cannot piggyback on a single VRT capture.

See Run a privacy audit.

Run FRT

A FRT feature run dispatches frt-test only. No page pillar is added automatically. Tracking overlay runs only when Verify tracking is explicitly enabled on the scenario.

See Running FRT tests.

Run Tracking (strict mode)

Tracking does not scan the whole site. It runs only entities linked in the tracking plan:

for each plan page with a linked VRT scenario → navigation + datalayer and network hit checks ;
for each plan event with FRT refs → linked FRT replay + per-step network overlay.

In strict mode (default), tracking navigations do not piggyback page pillars (a11y, perf, seo, security). Only tracking and linked FRT run.

If the plan links 8 pages and 5 FRT scenarios, cost is at most 8 + 5 jobs (parallelizable).

See Run a tracking audit.

Full audit

Full audit orchestrates four parallel groups:

Page batch — visual + a11y + perf + seo + security via shared capture ;
Privacy — triple-run per VRT scenario (privacy-test) ;
FRT batch — all project FRT features ;
Tracking — fan-out on linked plan entities (strict mode).

Plan-gated pillars or missing setup (e.g. no analytics plan) are skipped with a warning; the rest run normally.

See Run tests — Full audit.

CI / API entry points

Entry	UI equivalent	Useful parameters
`POST /api/tests/test`	Run VRT (+ page piggyback)	`scenarios[]`
`POST /api/tests/a11y` … `security`, `privacy`	Single page pillar	`scenarios[]`
`POST /api/tests/tracking`	Run Tracking	plan / scenarios
`POST /api/tests/frt`	FRT batch	`featureIds[]`
`POST /api/frt/run`	FRT feature run	`featureId`
`POST /api/tests/full-suite`	Full audit (scenario scope)	`scenarios[]`, `pillars[]`
`POST /api/quality-score/full-audit`	Full audit (whole project)	`pillars[]`
`POST /api/ci/run`	By `type` (`vrt`, `a11y`, `frt`, …)	see CI endpoints
Inngest cron per pillar	Scheduled single pillar	schedule config
Inngest `full-quality-audit`	Full audit	`capabilities.qualityPillars`

Rolling health and composite score

Page pillars feed page_health/{pageId}; functional feeds frt_health; the site aggregates via site_health/summary. The composite quality score on project home comes from this rolling health — not from a single pillar's latest run.

For project KPIs via MCP, use get_site_health / get_quality_score rather than one child run.

On this page