Admin governance

What the Users, Audit, and Analytics screens manage — and why the back-office is capability-gated, audited, and measured.

What it is

Three surfaces govern the admin area itself:

• Users (/admin/users) — who can do what. Access is capability-based: edit_data (the mutating tier) and view_audit (the read-only tier), granted through roles. Authentication rides Cloudflare Access; this screen manages the app-level authorization on top of it.
• Audit (/admin/audit) — the trail. Every successful mutation across the admin — catalog edits, syncs, theme flips, erasures, experiment lifecycle — lands as an audit record: who, what, when.
• Analytics (/admin/analytics) — the dashboards over the behavioral metrics, read-only, built on the metrics dictionary's single executable definitions.

Why it exists

The admin edits the data that decides what buyers are recommended — rules, tiers, tracks, catalog values. That power needs three checks. Least privilege: read-only roles (sales reading leads, a reviewer reading dashboards) shouldn't carry edit rights, so capabilities split the tiers and every guard is enforced server-side regardless of client state. Accountability: when a recommendation changes, the audit trail answers what changed and who changed it — and deliberately records only successful mutations, so a blocked attempt can't masquerade as an action. Trustworthy numbers: decisions get made on the dashboards, so every metric has one agreed definition, filtered of bots and staff traffic, before anyone counts it.

In the admin

Screen	How-to
Users	Admin access
Audit	Audit & validation
Analytics	Measurement plan — what the dashboards test and why

Learn more

• Behavioral metrics dictionary — every number's single definition.
• Measurement plan — the hypotheses the analytics exist to judge.
• Security review 2026-07 — the perimeter this governance sits inside.