Custom detection rules: teach the anonymizer your vocabulary
Detection rules let you always or never flag specific terms and RegEx patterns, and define your own entity types with their own placeholders like [CLIENT_1]. How to set them up in Stript, with examples for firms and companies.
Updated
Automatic detection covers names, addresses, IBANs, and the other standard identifiers. But every organization has vocabulary of its own: internal file-number formats, product names that look like person names, a client the AI keeps flagging that is actually your own firm. Detection rules close that gap: you tell Stript, once, what to always flag, what to never flag, and which categories of your own to use. Rules apply to every future detection run, across all projects.
The two rule kinds
- Always flag: every occurrence of the term or pattern is marked with high confidence as the PII type you choose. Use it for identifiers the automatic detection cannot know: internal client codes, project code names, a person always referred to by a nickname.
- Never flag: matches are dismissed automatically. They stay visible in the review list, dimmed and labeled with a rule hint, and you can restore any single one, so a rule can never silently hide something from you. Use it for your own firm’s name, standard letterhead lines, or a term that keeps producing false positives. You can scope a never-flag rule to one detected type only (“only when detected as Organization”) or to any type.
Both kinds support case sensitivity and whole-word matching, and both can be exported and imported as CSV, so a firm can maintain one rule set and share it across machines.
RegEx rules: match formats, not words
When the thing you want to catch is a format rather than a fixed term, switch the rule’s matching to a pattern (RegEx). Typical examples:
| Goal | Pattern (example) |
|---|---|
| Internal file numbers like AZ-2041 | AZ-\d{4} |
| Client codes like M-10234-K | M-\d{5}-K |
| Policy numbers like PV/2026/00123 | PV/\d{4}/\d{5} |
Patterns run under strict safety limits (a pattern that could match empty text is rejected at creation), and like all rules they take effect on the next detection run.
Custom entity types: your own placeholders
An always-flag rule doesn’t have to map to a built-in type. Give it a type name of your own, like CLIENT or PROJECT, and matches become a first-class category: they get their own placeholders ([CLIENT_1], [CLIENT_2]), their own group in the review panel, and their own on/off toggle for anonymization. Type names use letters and underscores (2 to 24 characters, umlauts are transliterated), and you can also assign a custom type by hand to any selection during review.
This matters for the round trip: a document where the parties appear as [CLIENT_1] and [OPPOSING_COUNSEL_1] is far easier to work with in an LLM prompt than one where everything is a generic [OTHER_3], and the restored document maps everything back exactly.
A worked example: a law firm’s rule set
- Never flag the firm’s own name (scope: Organization) so it stops appearing in every review.
- Always flag the recurring nickname of a long-standing client as Person.
- RegEx, always flag the internal file-number format
AZ-\d{4}with the custom typeAKTE, giving placeholders like[AKTE_1]. - Export the set as CSV and import it on every workstation.
From the next run, every matter document comes out pre-tuned: no noise from the firm’s own letterhead, and the internal identifiers are caught even though no general-purpose detector could know them.
Where rules live and what they cost
Rules are managed in Settings under Detection rules, are stored encrypted on your device like everything else, and are part of detection profiles, so a profile per matter type can activate exactly the rules that fit. Detection rules, RegEx patterns, and custom entity types are Stript Pro features; the free tier covers the full automatic detection.