KASHI — ROLE-AND-VISIBILITY ARCHITECTURE PERSPECTIVE Technical research memo for developers Date: 2026-04-21 Purpose Turn the role-and-visibility question into concrete architecture decisions for Kashi. This is not policy fluff. Visibility is part of the product’s technical validity, trust posture, and legal survivability. ================================================== 1. Executive judgment ================================================== Bottom line: Kashi should not be implemented as “one dataset + a few UI hides.” It needs a real two-lane architecture: Lane A — Private employee lane - Self-view - Private pattern exploration - Confound marking - Private evidence retention - Selective user-driven sharing - Access history Lane B — Safeguarded institutional lane - Manager self-mirror - Thresholded aggregate views - HR/compliance review queue - Case-bound restricted investigation - Audit-governed exceptional drill-down Core rule: Compute once when possible, but do NOT expose from one universal read model. Canonical facts may be shared internally in the backend, but read models, query scopes, filters, and even storage boundaries should differ by lane and role. If Kashi gets this wrong, it becomes bossware with nicer copy. If Kashi gets it right, it becomes narrow, politically survivable governance infrastructure. ================================================== 2. What the current project already implies ================================================== The existing materials already point to a strict visibility posture: - “Mirrors, not microscopes”: primary visibility is personal; upward visibility is aggregated and k-anonymized. - Managers are supposed to see their own behavior, not named subordinate telemetry. - The current stack already names five RBAC roles: Individual, Manager, HR-Compliance, Restricted Investigator, System Admin. - Aggregate views are supposed to be k-anonymous, DP-protected, and auto-suppressed for small groups. - Audit trails are already part of the posture. - Retaliation-risk work says private awareness, concern formation, and private evidence retention must not create employer-visible traces. - Trust work says constrained institutional visibility is first-order architecture, not just messaging. So the missing work is not invention. The missing work is operationalization. ================================================== 3. Architecture doctrine ================================================== 3.1 Primary doctrine 1. The institution must be allowed to see less than the technology could show. 2. The affected individual must be allowed to see more than the institution can see about them. 3. Most visibility restrictions must be enforced before rendering, not merely at rendering. 4. Raw-context access must be exceptional, reason-coded, auditable, and case-bound. 5. No employer role should receive ambient named behavioral telemetry about subordinates. 6. Small-group inferability is a real threat model, not an edge case. 3.2 Practical translation Bad pattern: - Single analytics table - Broad service-role access - UI decides what to hide - Manager/HR/CEO endpoints all query the same raw aggregates - “Don’t show the name” is treated as privacy Good pattern: - Canonical fact layer - Separate lane-specific read models - Query-time suppression - Role- and purpose-scoped endpoints - Case-bound event packages - Explicit anti-inference logic - User-visible access logs - No silent upgrade from private exploration to institutional review ================================================== 4. Recommended role model ================================================== Use six conceptual roles, even if five are currently exposed in the product: R1. Individual employee R2. Manager / people lead R3. HR / Compliance reviewer R4. Executive / CEO sponsor R5. Restricted investigator R6. System admin / platform operator Important: System Admin should be treated as infrastructure operator, not as a normal business-data viewer. If possible, split “support admin” from “behavioral-data investigator” completely. ================================================== 5. What each role should be allowed to see ================================================== 5.1 Individual employee Default visibility: - Own meeting-level and longitudinal metrics - Own explanations, caveats, confidence, confounds - Own trend windows - Own review-worthy events that involve them - Own access log - Own private evidence vault metadata and ciphertext references - Own selective-sharing controls Must also be able to: - Mark confounds - Dispute speaker attribution / transcript representation - Request review - Suppress or annotate misleading interpretations where policy allows - Preview exactly what would be shared if escalating Must NOT expose to others by default: - Page opens - Repeat viewing - Confound-marking - Vault creation - Draft report creation - Support-resource usage Interpretation: Private awareness is not institutional action. 5.2 Manager Default visibility: - Their own mirror only - Their own trends - Their own behavioral summaries - Their own explanation objects - Their own coaching prompts / reflection objects May also receive: - Team-level aggregate patterns only if thresholds are satisfied - No named subordinate trend lines - No named “this person is being targeted” outputs - No subordinate private concern states - No private evidence existence - No employee access-log information Hard restrictions: - No export from mirror - No performance-use route - No subordinate drill-through from mirror - No list of “who triggered concern” - No access to raw transcript snippets unless separately escalated under institutional process and with no conflict of interest Interpretation: Manager Mirror is self-feedback, not a covert personnel dashboard. 5.3 HR / Compliance Should not get a universal browsing console. Default visibility should be: - Review queue - Thresholded organizational patterns - Case intake objects - Minimal event packages - Case metadata - Audit trails - Access history for their own actions and broader reviewer activity where allowed Can see more than managers, but still not everything: - No ambient browse-all employee timeline - No free-form transcript search across the company - No automatic access to full raw data - No visibility into private employee states unless the employee shares or a thresholded institutional path formally opens Interpretation: HR/Compliance should see issues to review, not a workplace panopticon. 5.4 Executive / CEO Default visibility: - Aggregate roster-style view at per-manager / per-team / per-unit granularity - DP-protected / k-anonymous trend summaries - Relative change and queue burden - Actionable aggregate prioritization - No company-wide “health score” - No named employee telemetry by default Must NOT get: - Individual employee timelines - Free drill-down into raw meetings - Visibility into who is privately checking their own page - HR-style case details unless separately justified and permitted by process Interpretation: CEO visibility is for sponsorship and resource allocation, not for browsing people. 5.5 Restricted investigator This role should be dormant most of the time. Activation conditions: - Formal case opened - Reason code recorded - Need-to-know established - Scope approved - Audit trail on - Access window time-bounded Can see: - Bounded event package - Specific case-linked participants - Specific meeting windows - Limited relevant transcript-linked evidence objects if policy allows - Chain of access history - Context notes / confounds / disputes relevant to the case Must NOT get: - Open-ended org browsing - All meetings for a person by default - All meetings for a manager by default - Entire archive because “investigation” Interpretation: Investigator access is exceptional, scoped, and minimally sufficient. 5.6 System admin Default visibility: - Tenant, auth, billing, storage, job status, system health - Not behavioral content - Not private evidence contents - Not business-meaningful drill-down objects unless break-glass If break-glass exists: - Must be dual-approved - Time-limited - Fully logged - Visible to compliance review - Preferably generates user-visible notice unless prohibited by legal process Interpretation: Operational control plane is not behavioral visibility. ================================================== 6. Compute-once vs render-by-role ================================================== 6.1 Safe to compute once in canonical form These can exist in shared backend fact tables: - Meeting identifiers - Participant mapping - Turn timing facts - Overlap/interruption events - Response latency facts - Speaking share facts - Detector outputs - Confidence objects - Aggregation windows - Review-worthy event objects - Suppression flags - Role metadata - Meeting-type metadata - Audit references 6.2 Must be lane- or role-derived before exposure Do NOT expose canonical tables directly. Derive read models such as: - employee_self_dashboard_view - manager_self_mirror_view - hr_review_queue_view - executive_aggregate_roster_view - investigator_case_bundle_view These read models should already have: - row filtering - column filtering - aggregation rules - suppression rules - redaction - confidence labeling - anti-inference transforms - purpose tags Core rule: The frontend should never be trusted to turn a powerful record into a safe one. ================================================== 7. Hide at query layer vs hide at UI layer ================================================== 7.1 Must be hidden at query / policy layer These are too sensitive for UI-only hiding: - Named subordinate telemetry for manager role - Private employee page-open events - Confound-mark activity - Vault existence / vault activity - Draft report objects - Raw-context records for non-investigator roles - Small-N groups that should be suppressed - Data outside authorized case window - Cross-tenant rows - Fields blocked by role / purpose Enforcement options: - Postgres RLS - security-definer RPCs - backend authorization service - lane-specific schemas or views - query builders that require role + purpose + case scope - policy tests in CI 7.2 Can be additionally hidden at UI layer UI can add extra softness but not primary safety: - Visual redaction - Disabled export buttons - “insufficient group size” messages - explanation panels - caveat banners - confidence labels - delayed rendering until reason-code check passes UI is the last guard, not the first. ================================================== 8. Recommended data architecture ================================================== 8.1 Data planes Use at least four logical planes: A. Ingest plane - Raw transcript-linked artifacts - Speaker attribution - timestamps - ingestion quality - limited retention - tightly bounded access B. Analytics plane - Canonical turn/event facts - detector outputs - aggregation objects - confidence objects - suppression metadata C. Private employee plane - self-dashboard materials - confounds - disputes - private notes if any - private evidence vault metadata - selective sharing manifests D. Institutional review plane - review queues - case bundles - access reason codes - approvals - audit logs - minimal evidence packages Optional fifth: E. Security / ops telemetry plane - auth events - page access for security - but segregated from employer business analytics - no employer-facing BI on private exploration 8.2 Entity model suggestions Core entities: - org - user - role_assignment - meeting - meeting_participant - turn - detector_observation - aggregation_snapshot - review_event - suppression_decision - confidence_object - confound_annotation - dispute_object - private_share_bundle - case - case_scope - access_request - access_grant - access_audit - evidence_vault_item - legal_hold Critical point: Do not model “visibility” only as frontend navigation. Model it as first-class data and authorization objects. ================================================== 9. Query and authorization model ================================================== Every sensitive read should require at least: - actor role - actor org - lane - purpose - case scope if applicable - time window - target scope - suppression evaluation Suggested authorization signature: authorize(actor, action, resource, lane, purpose, case_id?, target_scope?) Examples: - authorize(manager_123, read, manager_self_mirror_view, institutional, self_reflection) - authorize(hr_9, read, hr_review_queue_view, institutional, threshold_review) - authorize(inv_4, read, investigator_case_bundle_view, institutional, formal_investigation, case_88) - authorize(user_55, read, employee_self_dashboard_view, private, self_awareness) Without purpose scoping, roles sprawl. HR is not one thing. An HR reviewer opening a threshold queue is not the same as an investigator reading raw context. ================================================== 10. Drill-down doctrine ================================================== 10.1 Default Aggregate-first. No casual raw-context drill-down. 10.2 Drill-down allowed only when all are true - Threshold condition met OR explicit user share OR formal case opened - Authorized role - Need-to-know documented - Reason code recorded - Scope bounded - Access logged - Anti-inference check passed - Minimum necessary context package generated 10.3 Drill-down package should prefer - event objects - bounded windows - timestamped references - detector explanations - confidence + caveat objects - relevant confounds/disputes - minimal transcript-linked snippets where necessary 10.4 Drill-down package should avoid by default - full transcript dump - entire person history - unrelated meetings - all participants’ raw context - open-ended search ================================================== 11. Anti-inference rules ================================================== This part is make-or-break. Even if names are hidden, identity can be reconstructed from team size, role structure, timing, or event rarity. Required anti-inference controls: - k-thresholding - auto-suppression for small groups - dominant-role suppression - batching - delay before showing new aggregates - window coarsening - role-bucket aggregation - redaction of rare combinations - no visibility into private page opens / vault creation / repeated self-review - no tiny-team “concern formation” indicators Rule: Kashi must defend against reasonable inference, not only direct disclosure. ================================================== 12. Retaliation-safe private states ================================================== The retaliation memo implies five states. The architecture should respect them explicitly. State 1 — Private awareness - self opens pattern page - self reads explanation - visible to: self only State 2 — Concern formation - repeated review - confound marking - support-resource usage - visible to: self only State 3 — Private evidence retention - vault creation - encrypted snippet preservation - visible to: self only State 4 — Selective sharing - employee chooses to share a bounded package - visible to: chosen recipient only State 5 — Formal case handling - institution opens defined workflow - visible to: approved case roles only Technical implication: Do not let states 1–3 leak into institutional analytics, notifications, queue counters, or manager-facing surfaces. ================================================== 13. Critical contradictions and risks ================================================== 13.1 “Not monitoring” is too absolute Technically, Kashi still processes workplace interaction data. So the architecture should not depend on rhetorical denial. It should depend on narrow scope and enforced limits. 13.2 CEO-first rhetoric can corrupt implementation If the team internalizes “CEO instrument” too literally, dev choices will drift toward broad executive visibility. That would directly undermine the worker-protective logic the docs otherwise defend. 13.3 UI-only RBAC is fake security If a privileged API can still fetch the row, the system is not role-safe. 13.4 Manager Mirror can silently mutate into subordinate surveillance This happens if: - named subordinate drill-through appears - mirror gets export - HR or leadership reuses mirror history in appraisal - admin can browse manager/subordinate pairs freely 13.5 HR browse-all is politically fatal A generic HR analytics console with person search is basically surveillance software with better vocabulary. 13.6 Investigator scope creep is likely unless built against If every case can query full history, “restricted investigator” is a label, not a control. ================================================== 14. Suggested implementation pattern ================================================== Phase 0 — Freeze doctrine - Write role/visibility matrix - Write lane doctrine - Write reason codes - Write “what does not become visible” list Phase 1 — Build canonical facts + lane-specific views - Canonical analytics tables - Lane-separated SQL views / materialized views - Role-purpose authorization layer - Policy tests Phase 2 — Employee private lane - self dashboard - confounds - access history - evidence vault metadata isolation - selective sharing preview Phase 3 — Manager self-mirror - self only - no subordinate drill-through - no export - no downstream performance integration Phase 4 — Institutional aggregate lane - HR threshold queue - executive aggregate roster - suppression + DP + batching Phase 5 — Exceptional access layer - case creation - investigator bundle generation - reason-coded approvals - bounded window package - audit + review cadence ================================================== 15. Acceptance criteria for devs ================================================== A. General - A role cannot retrieve data it is not allowed to see even if the frontend is bypassed. - Every sensitive endpoint requires role + purpose, not role alone. - Every drill-down action creates an immutable audit entry. B. Employee lane - Opening /app/me/pattern generates no employer-visible business event. - Confound-marking generates no manager/HR/executive-visible event. - Vault creation and activity metadata are user-private by default. - Employee can view access history for their own case-relevant records. C. Manager lane - Manager can see self mirror only. - Manager cannot query named subordinate behavioral telemetry. - Manager mirror cannot export raw event history. - Manager cannot infer whether a subordinate opened self-view or started evidence retention. D. HR / Compliance lane - HR sees queue objects, not browse-all person analytics. - HR cannot access raw transcript context without formalized reasoned path. - Queue entries are suppressed or delayed where small-N inferability risk exists. E. Executive lane - Executive views are aggregate-first, k-thresholded, and DP-protected where applicable. - No company-wide health bar. - No named employee-level drill-through by default. F. Investigator lane - Investigator access is impossible without case scope. - Case scope is time-bounded and target-bounded. - Investigator receives bounded event package, not automatic full history. - All accesses are logged and reviewable. G. System admin - System admin cannot casually browse behavioral data. - Break-glass access, if it exists, is dual-approved, time-bounded, and fully logged. ================================================== 16. Recommended dev decisions, bluntly ================================================== 1. Treat role-and-visibility as backend architecture, not UX. 2. Build the two lanes explicitly. 3. Use separate read models per role/lane. 4. Put anti-inference logic into queries and aggregation jobs. 5. Keep manager mirror self-only. 6. Make HR queue-based, not browse-based. 7. Make investigator access case-bound, not role-bound only. 8. Keep private employee states invisible until explicit share or formal threshold path. 9. Split admin operations from behavioral-data access. 10. Do not let commercial rhetoric widen the read surface. ================================================== 17. Final judgment ================================================== For Kashi, visibility architecture is the product. Not a settings page. Not a privacy appendix. Not a governance FAQ. The technical success condition is not just “can we compute the signals?” It is “can we compute them while making it technically difficult for the institution to see too much, too early, or for the wrong reason?” That is the architecture Kashi actually needs.