Data Flow & Isolation
Identity isolation by design
The path from employee conversation to organizational analytics never crosses the identity boundary. That's not a setting - it's an architectural property.
Architecture
From conversation to analytics
Each step in the data flow is a checkpoint. PII is scrubbed before storage. Identity is mapped to a pseudonymous participant ID and never rejoined to content. Analytics are derived only from content that has passed privacy screening.
Employee
Shares feedback
PII Scrubbing
Before storage
Names, emails, IDs removed
Identity Mapping
Isolated layer
Application: no access
Conversation
Pseudonym only
Identity never linked
Analysis
Themes & sentiment
Privacy screened
Analytics
Aggregated output
Thresholds enforced
Participant abstraction
How identity and content are permanently separated the moment a conversation begins.
When a conversation is created:
A pseudonymous identifier is created in the identity layer
Links real identity to pseudonym. Accessible only to background systems.
The conversation is created in the content layer
References pseudonym only. The application cannot look up the real identity.
Segment tags are snapshotted at conversation start
Tags are copied to the conversation. Even if the employee's role changes, the snapshot doesn't update.
The identity-to-content connection is permanently prevented
No application query can resolve the pseudonym back to the real identity.
Why pseudonyms?
Pseudonymous identifiers allow the system to group conversations by the same person (for privacy screening thresholds) without ever exposing who that person is. The mapping lives in a completely isolated layer that the application cannot access.
Why snapshot tags?
By capturing segment tags at conversation creation, we prevent a timing attack where someone could change an employee's role and re-run analytics to narrow down who said what. The snapshot is immutable.
Privacy guarantees
The architectural properties that make identity isolation trustworthy.
No reverse lookup
The application has no API, query, or mechanism to resolve a pseudonym back to a real identity. This is enforced at the database level.
Isolated storage
Identity mappings live in a separate schema with strict access controls. The application user has no permissions to read it.
Audit trail
Any access to identity data by support staff requires a governance case, is time-limited, and is logged in an append-only audit trail.
“The customer application cannot read identity mappings”
This is enforced architecturally - not by application logic, not by policy, but by strict access controls verified automatically on every deployment.