Data Spillage Handling: Naming Plan
Overview
The Data Spillage Handling feature is exclusively available in Enterprise Advanced and is designed to solve data security and compliance problems for DISC (Defense, Intelligence, Security, and Critical Infrastructure) market customers dealing with sensitive and classified materials.
This naming plan emphasizes nomenclature optimized for the DISC market while appending a reference to "Content Assurance" to ensure legibility for commercial enterprise customers. Naming decisions have been validated through direct testing with DISC customers and prospects (SAF AQLX, Canadian CSE and Armed Forces, FRA, Trafikverket, Naval Group, DOD CIO Special Access Programs Office).
Summary of updated terminology
Feature name: "Data Spillage Handling" — validated as the optimal name for the target DISC segment. In the DISC sector, "Spillage" is the definitive term of art signaling the software understands the gravity of classified data appearing on unauthorized systems.
Admin Console sub-label: "Content Assurance" — added as a cross-market bridge so non-DISC admins (e.g. global banking) can categorize the feature within their existing Information Governance or Risk frameworks.
Bot: Display name "Data Spillage Bot"; admin notification copy references "the Data Spillage bot".
End-user action: "Quarantine for Review" (menu + modal); button in the modal stays "Submit."
Notifications: "when content is quarantined for review" / "when the quarantine is dismissed."
Why "Quarantine for Review" instead of "Flag for Review"
In many DISC environments, "Reporting" or "Flagging" a peer is perceived as a serious administrative act that can trigger official security investigations or jeopardize clearances. To ensure users actually utilize the tool to catch data spills, we must use neutral, procedural language that reduces the "snitch" stigma.
"Quarantine for Review" achieves three goals:
Closes the Hostility Gap — shifts the focus from a "hostile act" against a peer to a "protective act" for the network. The post is treated as potentially contaminated data that needs to be isolated — a standard, non-punitive procedural step in defense environments.
Technical accuracy — the post is immediately removed from the channel; "Quarantine" accurately describes the technical state of isolation.
Strong action without alarm — authoritative enough to explain the sudden removal of content without being alarmist. Unlike standard social media moderation, this feature immediately removes content from all users' views and the name must match that gravity.
The phrase "for Review" reinforces that the user is not making a final judgment. Responsibility for determining whether an actual "Incident" occurred remains with a qualified Security Reviewer. This lowers the barrier to action and supports a "Safety First" approach where content can be restored if the reviewer deems it appropriate.
Naming surfaces and proposed changes
1. Admin Console
Location | Current copy | Proposed copy |
|---|---|---|
Sidebar ( | "Content Flagging" | "Data Spillage Handling" |
Page title ( | "Content Flagging" | "Data Spillage Handling" |
Enable toggle ( | "Enable content flagging" | "Enable Data Spillage Handling" |
Enable toggle help text | — | "When true, users can quarantine messages for review. Quarantined messages are sent to designated Content Reviewers, who can assess the content and take action." |
Content Reviewers section subtitle | "Define who should review content in your environment" | "Define who should review content that is quarantined for review in your environment" |
Content Reviewers > Per team configuration | "Configure content flagging per team" | "Configure content reviewers per team" |
Notification settings section subtitle | "Choose who receives notifications from the System bot when content is flagged and reviewed" | "Choose who receives notifications from the Data Spillage bot when content is quarantined for review" |
Additional settings section subtitle | "Configure how you want the flagging to behave" | "Configure options for the quarantine and review process" |
Admin console search: The feature must be discoverable via both "Data Spillage" and "Content Assurance" as search terms within the admin console.
URL: Updated to site_config/data_spillage in admin_definition.tsx. Add a redirect from content_flagging and document the change.
2. Content-review bot
Location | Current | New |
|---|---|---|
Bot display name ( | "Content Review" | "Data Spillage Bot" |
Bot username ( |
|
|
3. End-user: post menu and modal
Location | Current | New |
|---|---|---|
Post dot menu item ( | "Flag message" | "Quarantine for Review" |
Modal heading ( | "Flag message" | "Quarantine for Review" |
Modal subheading | "Flagged messages will be sent to Content Reviewers for review." | "This message will be quarantined and sent to Reviewers." |
Message preview title | "Message to be flagged" | "Message being quarantined for review" |
Comment required error | "why you're flagging this message" | "why you're quarantining this message for review" |
Note: Do not change rhs_root.mobile.flag / rhs_root.mobile.unflag — those are for Save Message / Remove from Saved (bookmark), not this feature.
4. Customizable Reason list
The Quarantine Dialog allows users to categorize the risk when quarantining a message. Reason codes are administrator-configurable so organizations can match their specific vernacular.
Classification mismatch | Universally understood across every DoD and IC customer. The single most common data spillage scenario. |
Need-to-know violation | Even if the classification level of the channel is correct, content may be shared with personnel who lack the specific program access or need-to-know. |
Personally identifiable information (PII) exposure | Clean, recognizable label. Covers SSNs, addresses, PHI, service records. Every organization — defense or otherwise — recognizes this. |
Operational security (OPSEC) concern | Broad enough to capture aggregation risks, schedule leaks, capability details. "OPSEC" is muscle memory for the target user base. |
Controlled Unclassified Information (CUI) violation | CUI shared in a channel or with recipients not authorized for its handling. This is governed separately from classified data, with distinct reporting and remediation requirements. |
Unauthorized disclosure | General-purpose catch-all for real incidents that don't fit neatly above — information released to unauthorized recipients where the reporter can't diagnose the specific violation type. |
Other | Escape hatch for anything outside standard INFOSEC categories. Reporters can provide specifics in the comment field. |
5. Reviewer / RHS and keep–remove modal
Location | Current | New |
|---|---|---|
keep_remove_flag_content_modal subtext | "reporter of the flag" | "the user who initiated the quarantine" |
data_spillage_report buttons | "Keep message", "Remove message", "View details" | Keep |
property_card.field.reviewer_user_id.label | "Reviewer" | Keep "Reviewer" (already generic) |
Component/constant names (e.g. DataSpillageReport, flag_post_modal) stay as-is; only user-visible strings change.
6. Server-side notification messages
These strings are user-facing and should align with "quarantined for review" and the Data Spillage Bot.
Location | Current (code/i18n) | New |
|---|---|---|
| "@%s flagged a message for review. |
|
7. API, routes, and code identifiers
API routes: TBD
Config/feature flags: TBD
i18n key IDs: TBD
8. Documentation
Update any end-user or admin docs that reference "Content Flagging" or "flag message" to "Data Spillage Handling" and "Quarantine for Review" / "quarantined for review" as appropriate.
Ensure documentation includes reference to "Content Assurance" for cross-market discoverability.