Upload Your Own Rules: Turning Your NDA, Brand Guide, and Policy Into a Live Pre-Send Check

A marketing associate at a payments company drafts a customer email. It reads: “We’re thrilled to finally talk about Project Halo, launching next Tuesday.” Every word is clean English. No profanity, no slur, no obvious red flag. A generic banned-words filter waves it through. The problem is that “Project Halo” is the internal code name for an acquisition under an NDA that has not closed, and “next Tuesday” is an embargoed date the legal team has not cleared. The rule that mattered was never a word on a list. It was a rule specific to this company, on this deal, in this quarter.

This is the gap between a generic content check and a policy that knows your organisation. A generic list catches the words any company would ban. It cannot catch your client names, your project code names, your embargoed launches, or the specific claims your regulator lets you make about your own product. Those rules live in a PDF that most staff read once during onboarding and never open again.

Why a generic list misses the risk that actually costs you

The expensive lines in litigation are rarely the ones a keyword filter would catch. Consider a real, anonymized example. A gaming and betting chief executive posted material company figures from a personal social account before the company disclosed them through official channels. The words were ordinary and upbeat. The problem was the disclosure rule: material information has to reach everyone at once, through approved channels. The result was a US Securities and Exchange Commission settlement under Regulation FD for USD 200,000. No generic banned-words list contains the phrase that caused it, because the phrase was fine. The context broke a company-specific and regulator-specific rule.

The pattern repeats across regulated industries. A pharmaceutical company was fined EUR 25 million for messages disparaging a competing generic to doctors. The damaging content was not vulgar. It was a claim the company was not permitted to make. Off-channel recordkeeping cases tell the same story from another angle: the SEC and CFTC levied over USD 2 billion in penalties across firms whose staff used unmonitored channels for ordinary business talk. In none of these did anyone type an obvious “bad word.” They broke a rule that was specific to their firm, their product, or their obligations.

A generic check has no way to know that “Halo” is confidential, that “guaranteed returns” is a claim your compliance team forbids, or that a named client cannot appear in an external thread until the deal is public. It does not know your rules because you never gave them to it. This general information is not legal advice, but the direction is clear: the risk that lands you in front of a regulator is usually organisation-specific.

The framework: what belongs in a machine-checkable policy

Not every clause in a policy PDF can be checked at the moment of writing. “Act with integrity” is a value, and a machine cannot flag it. The rules that a pre-send check can actually enforce fall into five types. Use this as a working framework when you decide what to hand a tool.

Three tests separate a checkable rule from an aspiration. First, is it concrete: does it name a term, a claim, or a category, rather than a sentiment? Second, is it observable in text: can a reader point to the exact words that break it? Third, does it have a clear owner: someone who can confirm the rule and update it when the embargo lifts or the deal closes? If a rule passes all three, a machine can watch for it. If it fails one, it belongs in training, not in an automated check.

The framework also forces a useful discipline. When you write “no disparaging comparison” you have to list the competitors and the claim shapes that count. That act of writing the rule down in checkable form is worth doing even before any tool touches it, because it turns a vague worry into a specific instruction your team can follow.

What changes when the check knows your actual rules

This is the VerbaPulse feature that maps to the framework above. You upload your own NDA, brand guide, or compliance policy, and the pre-send check flags against your organisation’s rules, not just a generic list. When the payments associate types the launch email, the check does not need to guess. It has your rule that “Project Halo” is confidential until the deal closes.

The output stays short and phrase-level, which is how the product actually writes. It highlights the specific span and offers a brief suggestion:

• Flagged: “Project Halo” → suggestion: use the approved public name or remove before sending.
• Flagged: “guaranteed 8% returns” → suggestion: “targeted returns, capital at risk.”
• Flagged: unreleased user figure in an external draft → suggestion: remove until the numbers are public.

No essay, no lecture. A person mid-sentence gets a short prompt and decides. That is the design intent: catch the careless line a well-intentioned employee simply did not notice, at the one moment they can still fix it for free. You can define these organisation-specific rules on the custom policies page, mapping each rule to the types in the framework above.

Where a pre-send check fits, honestly

Be clear about the boundary. A pre-send check is a front-end shield against accidental risk. It is the line a good employee would rewrite if only they noticed. It is not an adversarial security control. It will not stop someone who is determined to leak, and it is not a defence against a compromised or manipulated system. Treat it as the layer that reduces honest mistakes before they happen.

It also complements your existing stack rather than replacing it. Archiving and supervision platforms such as Smarsh and Proofpoint capture and review what was sent. A pre-send check sits earlier, so fewer problem messages reach those queues in the first place. One tool cleans up after the fact and preserves the record; the other reduces how often there is anything to clean up. They work well together, and each does a job the other cannot.

The takeaway

Take your NDA, your brand guide, and your live compliance policy, and pull out every rule that passes the three tests: concrete, observable in text, clearly owned. Turn those into the five rule types in the framework. That list is your machine-checkable policy, and it is useful even if you never adopt a tool, because it converts a static PDF into something a person or a system can actually enforce at the moment of writing.

If you want to see it working against your own rules, our 30-day Proof-of-Value Pilot runs up to 10 seats for EUR 120, credited to your plan if you continue. You can start by drafting your rules on the custom policies page.