Quickstart
Four ways in, ordered by how much they cost you. The first needs no account and takes ninety seconds; the last checks copy from wherever it is written. Each one says what it settles and what it does not.
Check something in ninety seconds, with no account
- Open the checkerIt runs entirely in your browser. Nothing you paste is sent anywhere, stored, or seen by us.
- Pick a sector packThere are 6: health and care, financial services, legal, recruitment, food and supplements, and a privacy sweep. These are rules we wrote, not yours.
- Paste something you have already publishedA post, a caption, an ad. Real copy, because a sample deck proves only that a sample deck passes.
- Read the counts, not just the marksA wavy underline means code decided it. Brackets mean a person has to. The counts beside them say how far the check actually reached.
What this settles. That the deterministic engine runs on your kind of copy and finds real things in it. It does not check your rules, because you have not written any yet, and a pack we wrote passing your content establishes nothing about your obligations.
Your first brand, and the rules under it
A trial is 14 days of every feature, with no card and no call. Signing up puts you straight into a first run rather than a dashboard, because an account with no brands has exactly one useful next step.
- Name the brandA client if you are an agency, a product line if you are in-house. It gets its own rules, its own sources and its own record, and nothing about it is visible from any other brand in the account.
- Take a sector pack, or bring your own rulesIf the account already has house rules — the standards that hold whoever you are working for — the first run checks against those and says so. Otherwise a pack runs and the screen names whose rules they are: ours, not yours yet.
- Paste copy and watch it catch somethingSame engine as the public checker, now with a real rule set behind it and a record in front of it.
What this settles. That the tool can express your regime, once the rules under it are yours. A pack is a starting point that somebody has to review — it is not privileged, and it is not hidden either: every rule says where it came from.
Writing a rule that blocks a release
A rule is four decisions, and the third is the one people get wrong.
- Which kind
- Nine of them. The kind decides what code can settle about the rule, so it decides whether a clean result means anything.
- What it says
- In your own words, because this is the sentence that appears on a release record and beside every finding. Write it for the person who will read it in a year.
- Which level it sits at
- Account, brand or campaign. The test is whose obligation it is — a rule belongs at the level of the party who carries the risk of breaking it. Push a client’s regime up to the account and it fires false positives on every other client.
- Blocking or advisory
- Blocking stops a release until somebody records a reason. Advisory is noted beside it. Both go on the record either way.
Then release something that breaks it. The release is refused, and getting past it means recording which of three things you mean — the rule is wrong, the rule does not apply here, or the rule is right and you are publishing anyway. See overrides and set-asides.
What this settles. That a house rule is enforceable rather than advisory-in-practice. A level below yours can tighten it and can never weaken or remove it — rule inheritance is the mechanism, and the refusal happens at the control rather than at the save.
Releasing, and reading what the record says
Every release writes one record, and the part worth reading first is not the findings. It is the per-rule statement of what each rule established: whether code checked it and it passed, whether a model reviewed it, whether nothing read it, or whether it was in force and out of scope for what was checked.
Four states that are never collapsed into a percentage, and a fifth for a sweep that found nothing without clearing anything. If that distinction is the reason you are evaluating this, start at what a result establishes.
What this settles. That you can hand somebody a document showing what was actually checked. It is evidence that a control ran, not a warranty that the content is compliant — where a rule needed human judgement and did not get it, the record says so, which is the sentence most tools in this category will not print.
The same engine, over HTTP
The review endpoint imports the checker the editor runs — the same function, not a port of it — so a Figma plugin, an Office add-in, an agent or a build pipeline gets the answer the studio would give, against the same rules.
curl -X POST https://<project>.supabase.co/functions/v1/review \
-H "x-api-key: cs_live_…" \
-H "Content-Type: application/json" \
-d '{
"workspaceId": "8f2c…",
"blocks": [{
"role": "body",
"location": "Heading 2",
"text": "A cure for chronic fatigue."
}]
}'Issue the key at Account → API keys. It is generated in your browser and only its hash is stored, so it is shown once. Everything on the review API describes something that runs today.
What this settles. That the check is the same wherever it is run. What it does not settle is whether your integration is honest: a response with an empty findings array is not a pass, and an adapter that renders it as one is making a claim the API refuses to make.
Where to go from here
- Concepts and vocabulary
- If any noun above was unfamiliar. Four levels, two names that shifted during a rename, and what a finding carries.
- The rule catalogue
- If you are deciding whether this can express the rules you already have.
- What a result establishes
- If somebody has asked you what “no issues found” actually means.
- Security and data handling
- If a questionnaire is what brought you here. Tenant isolation is next door.