For employees.
Your employer deployed ClarityLift. Here is what it sees about you.
This is not a marketing page. It is a receipt. Read it if you want to know, in plain language, what data is processed, what your manager actually sees, and what the product cannot do no matter who asks.
What happens to one message.
Every path a message in your workspace can take through the system. Read top to bottom. The diagram is exhaustive — there is no eighth step.
Message
lifecycle
Read ↓
Slack or Teams delivers an event to our webhook.
Your message reaches ClarityLift the same way any Slack/Teams integration receives events — through a webhook your admin authorized when they installed us.
Handler checks whether the event is a DM. If yes, the event is dropped.
Direct messages between two people never proceed. The check happens before classification, before storage, before anything else. The DM scope is not requested from Slack at install time, so in most deployments DM events never reach the webhook at all.
A fast pattern-matcher decides whether the message is worth classifying.
A lightweight matcher — length, structural features, a small rule set — filters out the obvious nothing: "ok", "ty", emoji reactions, bot messages, link previews. Most messages are discarded here. They are never sent to a language model, never written to the database, and no record of them is kept.
If the message passes, its text is sent to a language model once, in memory.
The remainder is classified. The text is held in memory for the duration of the provider call and then released. It is not written to our database. It is not written to logs.
The LLM provider does not retain the text.
We route through Azure OpenAI inside the Microsoft Azure tenant boundary and Anthropic under a Zero Data Retention contract. Neither provider stores the prompt or the response, and neither trains on either.
Azure path: prompt stays inside Microsoft's boundary; no provider-side logging of prompt or completion. Anthropic path: contractual ZDR; no user id metadata set on the request. Architecture page §07 covers retention posture in full.
A row is written to our database.
What remains, and what is stored, is a signal record. Seven conceptual fields. No user id. No message body. The two operational-metadata columns the table does carry — a platform message reference used once for idempotency, and an HMAC-keyed sender hash used to count distinct contributors — are documented below the schema. Neither can reconstruct what you wrote.
Nothing appears on the dashboard unless the team has 10 or more members.
Signals below the k-anonymity floor are refused at the write boundary. SignalFloorSubscriber.beforeInsert throws SignalBelowFloorError before the row is persisted — no suppression layer, no hidden rows, nothing to query. A team of 9 produces no visible output: not a dimmed reading, not "insufficient data," not a count. The dashboard surface is empty until the floor is crossed.
| Field | Type | What it is |
|---|---|---|
| organizationId | uuid | Which customer company this signal belongs to. |
| teamId | uuid | Which team in that company — never an individual. |
| channelId | string | Which channel the message was in. |
| signalType | enum | One of the published categories. No free-text labels. |
| severity | enum | low / medium / high. |
| confidence | float | Classifier score. 0.0 to 1.0. |
| detectedAt | datetime | When classification ran. |
| user_id | uuid | — not written. No column exists on this table. |
| message_text | text | — not written. No column exists on this table. |
| quote / excerpt | text | — not written. No column exists on this table. |
Three hard floors.
These are not policies. A policy is something a company can change. These are structural — enforced in code, in the database schema, and at the query layer. Turning them off is not a config option.
Three
commitments
Structural,
not policy
No DMs. Ever.
ClarityLift does not request the DM scope from Slack at install time. In workspaces where a prior install granted it, the handler drops DM events at step 2 of the pipeline above. There is no configuration that turns this on.
No team below 10 people produces output.
Below the k-anonymity floor, the product shows nothing — not a muted reading, not "insufficient data," not a blurred chart. The floor is enforced at the database insert subscriber and re-checked at the query layer. Every dashboard read passes through it.
No message text is retained.
The CL_HealthSignals table has no text column. There is no quote, no excerpt, no snippet. The LLM provider does not retain the prompt. No one at ClarityLift — not engineering, not support, not your account manager — can look up what you wrote.
What your manager sees — and what they do not.
Two inventories, placed side by side. The left column is the visible dashboard surface. The right column is the explicit list of absences. They are published together so the comparison is obvious.
Surface
inventory
Fig. 4.a
Absence
inventory
What your manager sees.
What your manager does not see.
What ClarityLift does and does not do with data across customers.
Sections 1 through 4 cover what happens to your data inside your own workspace. This section covers what happens across customers. The default is the strict version: your data stays in your tenant. Cross-customer aggregation is opt-in, not opt-out.
Cross-tenant
posture
Default:
opt-out
Your data does not leave your tenant unless your admin opts in.
ClarityLift can compute platform-level benchmarks across customers. It does not do that with your data unless your workspace admin has explicitly opted in via /dashboard/settings/platform-aggregation. The opt-in is reversible. Revocation removes your contribution from the next aggregation run within one cycle. Every flag flip is audit-logged.
When the aggregation pipeline ships and customers opt in, the floor mirrors the in-tenant 10-person rule. No benchmark publishes from fewer than 10 opted-in customers. The same k-anonymity principle, applied at the customer tier instead of the team tier.
Three different things your admin can agree to. Each is opt-in separately.
- Level 1. Anonymous platform aggregation. Your team-level signal data contributes to cross-customer benchmarks. Your customer name is never identified in any output. Output reads as “across N opted-in customers, the median team-level friction signal count is X.” Opted-in customers receive the same benchmarks back inside their dashboard.
- Level 2. Named case study. Your company is identified by name in a written case study with specific quotes, screenshots, or outcome metrics. Per case study, per specific content. You review and approve the version before publication. Withdrawal removes the case study from all surfaces within 14 business days.
- Level 3. Co-marketing. Your logo appears on the ClarityLift marketing site. You participate in joint webinars. You are publicly identified as a customer. Governed by a separate marketing agreement.
A customer can agree to Level 1 for benchmarks, Level 2 for one specific case study, and decline Level 3 entirely. The granularity is intentional.
The pipeline is not yet shipped. No customer data is being aggregated across tenants.
The opt-in flag, the aggregation pipeline, the customer-level floor, and the benchmark output surfaces are V1 architecture. Until they ship, no cross-customer benchmark can be computed because the runtime that would compute it does not exist. The disclosure above is the commitment that governs the system once it lands. The quarterly trust report (Q3 2026 onwards) reports the opted-in customer count, the aggregation methodology, and any benchmark publications under § 5 each quarter.
Procurement reviewer? The runbook governing this is published at docs/integrity/runbooks.md § Process 5. The case study consent process is § Process 6.
Your rights.
Five things you can do right now, each with the specific mechanism. This section is the one you want to screenshot. The links and endpoints do not change between revisions.
Actionable
rights
Bookmark
this page
How to verify this page.
Do not take our word for any of the above. Four verifications follow. They are designed so that you — or more likely your admin, or a security reviewer at your company — can check them against the running product, not against our marketing.
Verification
steps
V.1 – V.4
Trust nothing
claimed above.
Check all of it.
If the product cannot be shown to behave this way on a running workspace, the product is not behaving this way. A vendor promise is not evidence. A schema is.
im:history) is absent. This is the check that does not require trusting us — Slack shows it, not us.im:history · absent channels:history · present groups:history · present (invite-gated; Slack refuses reads unless the bot is added)
stored fields: 7 text columns: 0 user_id column: absent message text column: absent
dashboard surface: empty signal count visible: 0 "insufficient data": not shown k floor: k < 10 → silent
acknowledgement: 3 business days escalation path: published employer-bypass: yes
Most tools in this category hide behind a privacy notice written for lawyers. ClarityLift is built on the argument that you cannot earn trust from a team of people while also hiding what the product does from them.
Our posture: if the tool cannot survive being fully explained to the employees whose workspace it runs in, the tool should not ship.
This page is the test.