Offline AI QA: the checks that never leave the machine holding the draft.

The word gets used loosely, so it is worth pinning down. Here it means one thing: when you run a check, no copy of your input is transmitted to us. The rules are ordinary JavaScript that arrives with the page, and they execute against the string already in your browser. Nothing is posted, queued, logged or retained.

That is not the same as a tool that keeps working when the connection drops, although this one does after the page has loaded. The distinction that matters is where the analysis happens: on the device holding the file, or on a machine you have never seen and cannot inspect.

It is also not the same as a model grading a document. A language model has to receive the text before it can comment on it. A rule engine does not, because the rules were written before your text existed.

A draft produced with an assistant is unusually dense with material you would never publish. Customer names in an example row. An internal endpoint that should not be in a screenshot. A key someone pasted to see whether the model could fix the connection. A strategy paragraph that has not been announced, sitting under a heading that says draft.

Sending that to a cloud grader creates a second copy in a second system, under a second retention policy, often with the vendor's own model provider behind it. Most teams accept that on day one and spend the rest of the quarter on paperwork about it.

Offline checking removes the question instead of answering it. There is no new processor to document, no retention window to reconcile, and no region to worry about, because nothing leaves.

A tab is a capable runtime. Everything listed below executes locally, on ordinary inputs, in well under a second.

No check running on your machine can tell you whether a link still resolves, whether the API behaves as documented, or whether the argument in the sixth paragraph holds together. Those need the network, the live system, or a person who knows the domain.

Provenance is the clearest case. The image checks can report that a C2PA manifest is absent, present or damaged. They cannot validate the signature chain against a trust list, because that is a network lookup, and they cannot tell you whether a picture depicts a real event.

A report is therefore honest about scope: this is what ran, this is what it found, and this is where the rules stop. The last line is the useful one, because it tells you when a signature is worth paying for.

A model-judged review produces a different number every time you run it. That makes it useful for exploration and useless as evidence, because a re-run can quietly disagree with the result you attached to a release.

The rule engine is the opposite. The same input produces the same findings today and in two years, with the same severities, so a score can be cited in a ticket and defended in a review. When a rule fires, you can read the sentence behind it, decide whether you agree, and open the line it flagged.

That property is what makes an offline report something you can put next to a pull request, a campaign brief or a client deliverable without adding a paragraph of caveats.

The checks end where measurement ends: coherence, audience risk, taste and the calls that require a credential. Rather than pretending otherwise, the process hands those to a specialist in the discipline the work belongs to.

A reviewer is listed with a rate, a region and a typical turnaround, and they start from the automated findings, so their paid hours go to the judgement rather than to spot-checking the mechanical layer again. They record what they changed or requested and sign the verdict with their name on it.

You end up with two artefacts that travel with the deliverable: the deterministic report and the human sign-off, each stating a different kind of claim.

Run the check before the draft is pasted anywhere it will be hard to retrieve: the pull request, the CMS, the client email. It takes less time than reading the diff once, and it catches the class of defect that survives a skim precisely because the prose is fluent.

Then run it again over a sample of work you already shipped. The contents of the findings on published pages tell you more about the pipeline that produced them than any audit conversation will, and they give you a baseline to hold the next release against.

Neither habit needs an account. The console is open, the rules are readable, and the report is yours whether or not you save it.

A check has four states and none of them involves a request. Choose the content type, paste the text or pick an image, read the report, decide what to do about it. The type selector matters because the rules differ: a document gets heading and structure checks that would be noise applied to a fragment of JavaScript.

The report arrives as three things. A score weighted so a critical finding cannot be diluted by a tail of minor ones. A list of findings, each naming the rule, the severity and the text that matched. And a set of metrics — claim counts, sentence lengths, heading ranks, file weight — which tell you what the rules were looking at when they stayed quiet.

That last part is the one people skip, and it is the part that keeps the process honest. No findings on a two-hundred-word fragment means the fragment is clean; it says nothing about the article it came from. The metrics tell you which of those two reports you are holding.

Then the choices are small: fix the critical findings, fix the cheap ones, re-run to confirm the score moved for the reason you expected, and save the report if the work is going to someone who will ask about it. If you disagree with a finding, note why. That note is the seed of your own house rules and the first thing a reviewer should read.