The service is operated by Verand (“Verand”, “we”, “us”), a trading name of Brussel Investments, Inc., a Wyoming corporation. Questions about a pack, or a rule you think is wrong: support@verand.ai.
A compliance pack is a rulebook for one industry in one jurisdiction, written as code. You tell us your industry and your country when you onboard, and we load the packs that match. From then on, every draft the product writes is checked against them before you can publish it.
A pack encodes three kinds of rule:
- Banned claims. Language the governing body doesn’t permit, matched literally or by pattern. Each rule carries the regulatory basis it was written from, so you can see what it’s standing on.
- Required disclaimers. Text that has to be present before the piece is publishable.
- Citation requirements. Claims that can’t stand in your content without a source attached.
Packs stack. A base layer applies to every site we touch, an industry layer sits on top of it, and a jurisdiction layer on top of that. Your own banned phrases stack on all three. Every violation the gate reports is stamped with the pack and the pack version it came from, so a block traces back to a specific rule in a specific rulebook rather than to a verdict nobody can inspect.
The checks are deterministic. They’re code that either matches or doesn’t, not a model asked for an opinion, so the same draft gets the same answer every time it’s run and two people reviewing it see the same thing.
Verand’s compliance packs are AI researched and operator reviewed. A licensed attorney did not review them.
In order: the rules are researched against the governing body’s own published material, encoded as code, and then read line by line by a Verand operator before the pack ships. That operator is a person, and that person isn’t a lawyer. No attorney, no law firm and nobody admitted to a bar has reviewed any pack in this product.
The review status lives inside the pack file rather than in marketing copy, so the label
can’t drift away from the thing it’s labelling. Packs that have been through the
operator pass are marked internal-reviewed. Packs that haven’t yet are
marked draft, and several are, today. A third status exists in our schema for
attorney review. Nothing carries it. We wrote the field before we had anything to put in it,
and until a licensed attorney has actually read a pack, nothing will.
That tier gets added when the business can pay for it properly or a buyer’s procurement requires it. When it happens, it’ll be stated here with the date and the scope of what was read. It won’t be implied, and it won’t arrive as an adjective in a feature list.
This is the sentence we hold ourselves to, and it’s meant to be read literally:
Validated against [the governing body]’s rules. AI researched and operator reviewed. Your counsel confirms applicability. Not legal advice.
Clause by clause:
- Validated against. A check ran, and the rule it ran was written from that body’s published rules. It doesn’t mean the body has seen our check, approved it, or knows Verand exists.
- AI researched and operator reviewed. Exactly the two steps in the section above, and no third one.
- Your counsel confirms applicability. Whether a rule reaches your firm, your offering and your facts is a judgment we aren’t qualified to make and don’t make. That part stays with you.
- Not legal advice. Literally that. Nothing in the product, in a pack, or on this page is legal advice.
Our competitors are generally vaguer than this, and vagueness reads as strength right up until somebody has to defend it. We’d rather be the vendor whose claims survive a procurement review than the one whose claims got it through the door. If you ever see a Verand surface describe a pack in stronger terms than this page does, that’s a defect and we want to hear about it: support@verand.ai.
Here’s the part people don’t expect: the review label changes nothing about what
gets blocked. It describes who read the rulebook. It has no bearing on whether a rule fires. A
pack marked draft blocks a violation exactly as hard as a pack marked
internal-reviewed. We don’t soften a gate to match a modest label, and we
don’t inflate a label to match a firm gate.
Hard tier rules stop publication outright. These are the unambiguous, lawsuit-class claims, the ones no context rescues:
- guaranteed returns, or a guaranteed outcome of any kind;
- “can’t lose” and its relatives;
- a required disclaimer that isn’t there;
- a claim that breaks the rules of the jurisdiction the piece is aimed at.
There’s no override on a hard tier rule. Not for you, not for your account owner, not for us, not by support ticket. The piece doesn’t publish until the language changes.
Some counts, since they’re more use than adjectives. Across the packs shipping in the product today there are 70 banned-claim rules. 43 are hard tier and can’t be overridden by anybody. 3 are review tier, which the next section is about. The remaining 24 raise a warning and don’t block. We counted those out of the rule files in our own repository on 12 September 2026, and they move as packs are revised, so read them as a snapshot rather than a specification.
A deterministic check can’t always tell a violation from ordinary professional vocabulary. “Risk-free” is the standing example: in a pitch it’s a claim nobody may make, and in a discussion of the risk-free rate it’s just the name of the Treasury benchmark. Rules with that problem are flagged as review tier, and a review tier block can be lifted.
Lifting one costs something, deliberately:
- it takes a signed-in operator, so there’s a name attached;
- a written justification is required, and a couple of words won’t clear the bar;
- who overrode it, when, and the reason they gave are recorded against that article.
It applies to one rule on one article. There’s no global switch, no “ignore this rule on this site”, and no way to turn the gate off. Overriding the same rule on the next article means writing the justification again.
An override aimed at a hard tier rule does nothing at all. The flag is per rule, and the validator ignores an override on a rule that doesn’t carry it. It doesn’t fail quietly and let the piece through. The block stands.
Being on record is the whole point. An attributed, logged override by the credentialed professional whose licence is the thing at risk isn’t a hole in the gate. It’s the honest way to handle a rule that can’t see context, and it’s a different thing entirely from a label claiming a lawyer signed off.
Verand isn’t a law firm. We’re not your counsel, we don’t hold an attorney-client relationship with you, and using the product doesn’t create one.
A pack is a tool that catches things. It isn’t an opinion that you’re compliant. A clean gate means every rule we encoded passed on this draft. It doesn’t mean the content is lawful, and it can’t: we don’t know your filings, your client relationships, your offering documents, your state’s overlay on the model rule, or what your regulator said to you last year.
So the gate is a floor, not a ceiling. It clears out the errors that are mechanical and repetitive, which is most of them by volume, and leaves you the judgment calls, which is where your expertise was always the point. Every draft the product writes lands in your review queue. Publishing is something a person does.
If your practice is regulated, have somebody licensed in your jurisdiction review what you publish. We build the product on the assumption that you will, and no part of it is designed to replace that person.
Rules go wrong in two directions. One fires on content that’s fine. The other misses content that isn’t. Both are defects in the pack, and neither is something you should be quietly working around.
Tell us at support@verand.ai. The useful report is the rule ID from the gate readout, the sentence it fired on, and a line on why it’s wrong. If you only have one of those, send it anyway.
A false positive gets fixed in the rule, so the next person never meets it. The worked example is the one above: the risk-free rule was firing on “risk-free rate”, the ordinary name for the Treasury benchmark. The fix was a set of exception contexts written into the rule itself, shipped in the base pack’s next version. It wasn’t an instruction to keep overriding it. An override is the exception; a rule that needs overriding routinely is a rule we haven’t finished.
That’s why the overrides get read. One rule overridden again and again, with reasons that hold up, is a rule that needs changing rather than a customer who needs watching.
A false negative is the more serious kind and the harder one for us to find alone, because nothing surfaces when a check doesn’t fire. If you know of language your regulator objects to and the gate let it through, that’s the most valuable message you can send us. Pack changes are versioned, and the version moves when a rule does.
Sending this page to your compliance officer or your counsel? That’s what it’s for. It’s written to be read literally, and we’d rather answer their questions before you buy than after.