# Checks and verdicts

> The machine checks Checkbox runs at each lifecycle stage, what pass, fail, needs_review and not_applicable mean, and how the compliance status is computed.

A **check** verifies one observable thing — "the consent checkbox is not pre-checked", "a trial reminder arrived inside
the window". Checks are implemented once and reused by every law that requires the same thing; the
[catalog](https://checkbox.site/docs/concepts/requirements) maps requirements to checks.

## Verdicts {#verdicts}

| Status | Meaning |
|---|---|
| `pass` | Observed, and what was observed meets the requirement (an automated assessment, not a legal determination). A check never passes for lack of data. |
| `fail` | Observed, and it does not meet the requirement. The result says what was seen and how to fix it. |
| `needs_review` | Checkbox lacks the evidence to decide, or a person must judge (for example "clear and conspicuous" on a page Checkbox cannot restyle). The result says which. |
| `not_applicable` | No applicable requirement uses the check (for example trial checks without a free trial). |

A preflight result's `verdict` is the worst status among its checks: `fail` > `needs_review` > `pass`
(`not_applicable` when nothing applies).

## Status labels {#status-labels}

Every verdict also carries a user-facing `compliance_status` that says what to do about it. The machine `status` above
never changes; the label is computed from it, from the evidence and from the reason Checkbox gave.

| `compliance_status` | Label | When |
|---|---|---|
| `needs_fix` | Needs a fix | Every `fail`, and the `needs_review` results that are a clear gap in the legal floor (for example "says *renews automatically* but not *until you cancel*", a price that contradicts Stripe, consent implied by a plain "Subscribe" button). `compliance.fix` is the one change. |
| `pending_live_check` | Looks compliant — live check pending | Everything Checkbox can see is right, but the live event has not been observed: an email whose template passes but was not seen sent for a real event, a cancellation that worked on screen but is not confirmed in Stripe, a reminder that is not due yet, a page judged from static HTML. `compliance.pending_live_check` says what and how it completes (a date, "run a proof", "BCC real sends"). **Counts as compliant.** A content problem never lands here. |
| `verified_live` | Verified live | A pass that rests on a live event: an email seen sent, a cancellation flow run and confirmed. |
| `your_call` | Your call | A real decision for a person: a notice period or minimum term in your terms, New York price-increase consent, a text in a language Checkbox does not read. `compliance.question` has one question and the recommended answer. |
| `compliant` | Compliant / Looks compliant | A pass, or a grey area or stylistic judgement call (Stripe's own small grey custom text, an adjustable quantity) with a short `compliance.note`. |

Sites, evaluations, plans and check results roll these up over the **required** checks: `needs_fix` if any check needs
a fix, else `your_call` if a decision is open, else `compliant` — "Compliant · 2 live checks pending".

## Protection levels {#protection-levels}

Every check and plan task has a tier: **required** (the legal floor; the only tier that can make a site not compliant),
**recommended** (clearer records beyond the legal floor, conversion-neutral: consent receipts, a cancellation confirmation email, the
billing portal's cancel switch, a renewal section in your Terms) and **extra** (a checkbox per term, a pre-purchase
summary). A site's `protection_level` decides what the plan lists: `minimum` (required only), `balanced` (default:
required plus recommended suggestions, collapsed, never blocking) or `maximum` (everything). See
[Compliant checkouts that convert](https://checkbox.site/docs/guides/compliant-checkouts-that-convert).

## Evidence sources {#sources}

| Source | What it provides |
|---|---|
| Synthetic shopper | Headless Chromium visits the checkout as a shopper in each state (timezone and location; regional proxies where configured), on desktop and mobile, optionally completes a sign-up and tries to cancel online |
| Snippet | What real visitors see on your own pages, including A/B variants; content changes trigger a re-scan. Snippet captures corroborate: they never produce a pass on their own |
| Billing platform | Plans, trials, portal and checkout settings; webhooks become lifecycle events |
| Email | Your acknowledgment and reminder emails, BCC'd to the site's inbound address or received during a [test subscription](https://checkbox.site/docs/guides/test-runs) |
| Policies | Your Terms, refund and cancellation pages, fetched and checked for consistency |

## Every check {#all-checks}

### Sign-up

| Check | What it verifies | Laws that require it |
|---|---|---|
| `signup.disclosure.autorenew_language` | Discloses that the subscription renews automatically until canceled | 25 jurisdictions |
| `signup.disclosure.price` | Discloses the recurring charge amount | 22 jurisdictions |
| `signup.disclosure.frequency` | Discloses the billing frequency | 17 jurisdictions |
| `signup.disclosure.cancellation_policy` | Discloses the cancellation policy and how to cancel | 24 jurisdictions |
| `signup.disclosure.trial_terms` | Discloses free-trial length and the charge after the trial | 16 jurisdictions |
| `signup.disclosure.term_length` | Discloses the length of the renewal term (or that service is continuous) and any minimum purchase obligation | 20 jurisdictions |
| `signup.disclosure.proximity` | Terms appear before the purchase button and in visual proximity to it | 16 jurisdictions |
| `signup.disclosure.conspicuous` | Terms are clear and conspicuous (size, contrast, not hidden) | 27 jurisdictions |
| `signup.consent.affirmative` | Obtains affirmative consent to the automatic-renewal terms | 20 jurisdictions |
| `signup.consent.not_prechecked` | Consent checkboxes are not pre-checked | 20 jurisdictions |

### Acknowledgment

| Check | What it verifies | Laws that require it |
|---|---|---|
| `confirmation.email.sent` | Sends an acknowledgment after sign-up in a retainable form | 15 jurisdictions |
| `confirmation.email.terms` | Acknowledgment restates the automatic-renewal terms | 15 jurisdictions |
| `confirmation.email.cancellation_instructions` | Acknowledgment explains how to cancel | 15 jurisdictions |
| `confirmation.email.trial_terms` | Acknowledgment explains how to cancel before the trial converts to paid | 12 jurisdictions |

### Reminders

| Check | What it verifies | Laws that require it |
|---|---|---|
| `reminder.trial_ending` | Sends a reminder before a free trial converts to a paid subscription | 13 jurisdictions |
| `reminder.annual_renewal` | Sends a renewal reminder before long-term (e.g. annual) subscriptions renew | 22 jurisdictions |
| `reminder.annual_terms_notice` | Sends an annual reminder of the subscription terms and how to cancel (incl. monthly/continuous plans) | 5 jurisdictions |
| `reminder.charge_notice` | Sends a notice before (or promptly after) recurring charges where required | 2 jurisdictions |
| `reminder.price_change` | Gives advance notice of price changes | 16 jurisdictions |

### Cancellation

| Check | What it verifies | Laws that require it |
|---|---|---|
| `cancel.online_available` | Consumers who signed up online can cancel online | 19 jurisdictions |
| `cancel.mechanism_findable` | Cancellation option is easy to find (e.g. prominent link in account) | 25 jurisdictions |
| `cancel.flow_friction` | Cancellation is not obstructed (no forced calls/chat, limited save offers, few steps) | 18 jurisdictions |
| `cancel.confirmation` | Confirms the cancellation to the consumer | 12 jurisdictions |
| `terms.cancellation_policy_consistent` | Terms of service do not contradict online cancellation (no "no cancellations" / cancel-by-phone-or-mail clauses) | 2 jurisdictions |
| `terms.refund_policy_consistent` | Refund policy is consistent with refund / money-back claims made in marketing and checkout | 1 jurisdiction |

### Billing settings

| Check | What it verifies | Laws that require it |
|---|---|---|
| `config.portal_cancel_enabled` | Billing platform self-serve cancellation is enabled | 19 jurisdictions |
| `config.trial_reminder_enabled` | Billing platform trial-ending reminder emails are enabled | 13 jurisdictions |
| `terms.renewal_terms_present` | Terms of service state the automatic-renewal terms and how to cancel | 1 jurisdiction |

## Severity, status and certificates {#status}

Each finding's severity is the strictest among the requirements that use the check: `critical`, `high`, `medium` or
`low`. A site has **one status**: Compliant (optionally "· N live checks pending"), Needs a fix, Not set up yet, Not
checked yet or Your call, counted in tasks (`compliance.label`, e.g. "2 fixes needed · 1 to set up"). What to do next is
**one to-do list**: the [compliance plan](https://checkbox.site/docs/guides/compliance-plan)'s ordered open tasks, the same in the dashboard,
emails, MCP and the CLI. Findings are the evidence behind each task. There is no numeric score. A [monitoring certificate](https://checkbox.site/docs/concepts/evidence#certificates) uses a stricter tier:
no critical or high check fails, no critical check is left at `needs_review`, and no high-severity obligation is
without any evidence. A "live check pending" counts as compliant on your dashboard (its content passed), but not toward
a certificate until it is observed live.

## Reproducibility {#reproducibility}

Every result records `rules_version`, `catalog_version` and `catalog_hash`. Preflight checks are deterministic: the
same input and the same `as_of` date give the same verdicts.