Kashi — Rollout-Operability Perspective
Technical research synthesis for developers
Date: 2026-04-21
Purpose: turn rollout-operability into concrete system requirements, control-plane logic, runtime rules, and acceptance criteria.


Executive judgment

Bottom line: rollout-operability is not a policy appendix. It is part of the product architecture.

Kashi is already directionally strong on bounded visibility, deterministic detectors, RBAC, k-anonymity, auditability language, and refusal of content/affect/performance use. But those are still not enough for real pilot launch. The missing layer is an explicit rollout state machine: what must be true before activation, what system states exist during pilot, what gets paused when trust or access controls fail, how policy changes are versioned, and how challenge/correction propagates through downstream data products.

The blunt version:
- If Kashi launches without hard gates, it will be experienced as a monitoring system with unusually polished prose.
- If it launches without protected private states, it creates retaliation-sensitive metadata leakage.
- If it launches without rollback and decommission procedures, every rollout promise is reversible in practice and therefore weak.
- If it launches manager/executive surfaces before worker-safe self-view + challenge controls are proven, the sequencing itself will damage trust.

So the technical requirement is not “be careful.” It is: build a rollout control plane.


1. What the current Kashi materials already establish

Current project materials already provide a usable base layer:
- structural interaction metadata, not employer-facing content surveillance
- deterministic production detector path
- role-based presentation with k-anonymity and differential privacy intent
- no performance/promotion/discipline/compensation use
- auditability and review-worthy events rather than binary verdicts
- victim-explainer direction, user-marked confounds, and victim-owned evidence-vault plan
- real auth, multi-tenant schema, RLS, strict TypeScript, unit tests, deterministic re-run behavior, and build-time evaluation harness

Those are not minor implementation details. They are the legitimacy core of the product.

But the same documents also show the gap:
- rollout research already says launch must be treated as a governance-program launch, not a normal software rollout
- launch gates are named, but not yet fully converted into runtime controls or product-state transitions
- labor / worker-representation materials already demand representative consultation, auditability of rules, and material-change triggers
- retaliation materials already show that private awareness, concern formation, and private evidence retention must not create employer-visible signals
- progress deck already shows public install/governance/demo routes, but not yet a hardened rollout state machine for real customer deployment

This means the project is past the “do we need controls?” stage. It is now at the “encode them in the system or the story is fake” stage.


2. Critical diagnosis: what is still weak from an operability standpoint

2.1 Values exist; activation logic does not
Current materials say what Kashi refuses, but not yet with enough precision what conditions must be satisfied before a tenant can move from shadow mode to worker self-view, from worker self-view to manager mirror, or from manager mirror to executive aggregate view.

2.2 Challenge is named; propagation semantics are not
It is not enough to say transcript accuracy and context can be challenged. The system needs clear propagation rules:
- what gets hidden while under review
- whether aggregates recompute immediately or only after adjudication
- whether already-viewed events remain visible
- whether event IDs are tombstoned or versioned
- what happens to downstream exports, summaries, caches, and alerts

2.3 Pause/decommission is mentioned; incident handling is not yet operationalized
A serious deployment needs machine-readable triggers and operator playbooks, not just a steering-group aspiration.

2.4 Anti-retaliation has to be implemented as telemetry partitioning
The retaliation memos are right: the dangerous leak is not only content. It is the fact that a person opened their own pattern page, marked confounds, created a vault, or drafted a report. If those events enter employer-facing analytics, Kashi undermines its own protective thesis.

2.5 Material change is a product event, not just a legal event
If a tenant expands inputs, retention, role access, meeting scope, or downstream use, that is not a quiet admin setting change. It is a governance transition and must trigger re-consultation / re-approval logic.

2.6 Rollout sequencing is still too narrative-heavy
The research is explicit: do not treat worker self-view, manager mirror, and executive views as symmetrical launches. They have different power implications. The control plane has to encode that asymmetry.


3. Design doctrine for rollout-operability

Kashi should treat rollout as a controlled progression through explicit deployment states.

Recommended states

State 0 — Build / Internal Test
Purpose: developer testing and seeded scenarios only.
Data allowed: synthetic or explicit internal test data.
Institutional visibility: none.

State 1 — Shadow Ingestion
Purpose: verify transcript ingestion, parsing, diarization confidence, and detector stability without exposing user-facing behavioral outputs.
Data allowed: real in-scope pilot meetings.
Views allowed: governance-team ops view only; no employee/manager/executive behavioral dashboards.
Key requirement: workers already notified before reaching this state.

State 2 — Worker Self-View Only
Purpose: validate comprehension, challenge workflow, confound handling, and private evidence retention.
Views allowed: employee self-view only, plus tightly limited governance review.
Prohibited: manager mirror, executive aggregate, employer-side named drill-down.

State 3 — Manager Self-Mirror
Purpose: introduce bounded self-correction lane after worker-safe controls are proven.
Views allowed: manager sees own behavioral summaries only; no subordinate concern states; no comparative leaderboard.
Prerequisite: challenge SLA, access logs, and anti-retaliation telemetry partition proven in State 2.

State 4 — Executive Aggregate / Roster
Purpose: limited organizational hotspot visibility under k-thresholds and suppression logic.
Views allowed: aggregate-only by default; no open browsing; tightly reason-coded drill-down only if separately permitted.
Prerequisite: trust review checkpoint passed, error rates acceptable, small-team inference mitigations validated.

State 5 — Formal Case Support / Exceptional Access
Purpose: defined institutional procedure with auditable access under necessity rules.
Views allowed: minimal necessary event package, bounded windows, case-linked review only.
Prerequisite: explicit institutional workflow, reviewer role assignment, reason codes, logging, and anti-retaliation controls.

Do not skip states.
Do not let customer admins freely jump states.
State transition should require artifact checks plus product-enforced eligibility.


4. Pre-launch gate model that should be encoded, not merely documented

Gate 1 — Scope
System requirement:
- tenant must define in-scope and out-of-scope meeting classes before activation
- system must support meeting-class tagging, default exclusions, and external/guest flags
- meetings lacking sufficient scope metadata should default to no-analysis / hold state

Minimum outputs:
- meeting scope policy bundle
- inclusion/exclusion rules
- external participant handling rule
- fallback mode for unsupported meeting types

Recommended default exclusions:
- candidate interviews
- grievance / complaint handling meetings
- legal strategy / privileged meetings
- medical / wellness discussions
- ad hoc meetings with many externals
- customer meetings in MVP unless separately justified

Gate 2 — Notice
System requirement:
- policy notice, pilot notice, and just-in-time meeting notice must exist before ingestion begins
- notice version must be stored and linked to tenant activation version
- in-product explanatory notice must be present in all user-facing views

Important: notice is not passive copy. It is part of the control record.

Gate 3 — Access
System requirement:
- RBAC matrix must be configured before any behavioral view is enabled
- every non-self-view access action must require a reason code
- access-log visibility for affected individuals must exist
- manager/executive views must be impossible to enable if audit logging is off

Gate 4 — Challenge
System requirement:
- users must be able to challenge transcript text, speaker attribution, contextual confounds, event retention, and summary wording
- challenged objects must enter a review state
- affected downstream metrics must be marked as provisional or suppressed until resolved where applicable

Gate 5 — Anti-misuse
System requirement:
- product should not expose direct pathways for performance/promotion/discipline use
- admin UI should force acceptance of prohibited-use policy before activation
- unusual access patterns should trigger monitoring and review

Gate 6 — Readiness
System requirement:
- tenant must record sponsor coalition, representative consultation status, and manager briefing completion before state transition beyond shadow mode

Gate 7 — Exit
System requirement:
- tenant must define pause triggers, rollback plan, pilot sunset behavior, and decommission path before any live tenant moves past shadow mode


5. Required technical subsystems

5.1 Rollout control plane
This is the missing backbone.

Needed objects:
- PolicyBundle
- DeploymentState
- ScopeProfile
- NoticeBundle
- AccessPolicy
- ChallengePolicy
- MisusePolicy
- ExitPolicy
- ChangeRequest
- ActivationApproval

Recommended fields
PolicyBundle
- id
- tenant_id
- version
- effective_at
- scope_profile_id
- notice_bundle_id
- access_policy_id
- challenge_policy_id
- misuse_policy_id
- exit_policy_id
- approved_by_roles
- representative_consultation_status
- change_class (major / minor / emergency)
- rollback_target_bundle_id
- status (draft / approved / active / superseded / revoked)

DeploymentState
- tenant_id
- current_state
- entered_at
- entered_by
- source_policy_bundle_id
- transition_reason
- guard_checks_passed
- pending_blocks

The control plane should be versioned, queryable, and auditable. No hidden admin flips.

5.2 Scope engine
Purpose: determine whether a meeting is analyzable, how it is classified, and what controls apply.

Inputs
- platform metadata
- calendar metadata
- organizer role
- participant count
- internal/external mix
- recurrence pattern
- meeting title / tags if permitted
- optional tenant-managed meeting-class mapping

Outputs
- meeting_class
- analysis_mode (full / observation-only / excluded / hold-for-review)
- notice_requirement
- retention_profile
- allowed_views
- challenge_defaults

Observation-only mode is important. Unsupported or low-confidence meeting classes should not generate review-worthy events by default.

5.3 Notice engine
Purpose: guarantee that deployment notice is not merely policy PDF theater.

Required behavior
- store notice versions per tenant
- attach just-in-time notice state to meeting/session
- expose in-product explanation of what each metric means and does not mean
- log that notice was presented at the system level without converting it into “consent solved the problem” logic

5.4 Access engine
Purpose: enforce bounded visibility.

Requirements
- self-view is default
- manager sees own mirror only unless explicitly different and still bounded
- executive sees aggregate-only above threshold
- exceptional drill-down requires case linkage and reason code
- every drill-down creates access-log entry visible to affected individual
- small-team anti-inference suppression must be central, not optional

Reason-code examples
- transcript correction review
- speaker attribution dispute review
- formal case handling
- legal-hold verification
- security incident investigation

Bad pattern to avoid:
"admin" as a universal bypass role with no reason code.

5.5 Challenge and correction engine
This must be treated like a real subsystem, not a comment box.

Challenge types
- transcript-text challenge
- speaker-attribution challenge
- contextual confound assertion
- retention objection
- summary wording objection
- review-worthy event dispute

Required lifecycle
submitted -> triaged -> under_review -> resolved_upheld / resolved_rejected / resolved_modified -> propagated

Propagation rules must be explicit.
Examples:
- if speaker attribution is challenged for an interruption event, mark the event provisional immediately
- if an event is suppressed, remove it from manager/executive views and recompute dependent aggregates
- if summary wording changes, retain version history but update visible narrative
- if retention is successfully challenged, tombstone the retained object and propagate deletion/suppression to all derivative stores except where legal hold applies

5.6 Protected private states / anti-retaliation layer
This is not optional.

Protected states that must create no employer-visible signal by default:
- opening own pattern page
- repeated self-review
- confound marking
- support-resource clicks
- vault creation
- vault activity
- draft report creation
- draft edits

Technical requirement:
protected-route telemetry must live in a segregated namespace inaccessible to managers, HR, and executive product users.

Do not mix:
- product analytics for employer/governance views
with
- sensitive security/reliability logs for protected private routes

5.7 Evidence minimization and share-preview flow
Default institutional sharing should prefer:
- event objects
- bounded context windows
- redacted third-party context
- explicit recipient choice
- share preview before transmission

Never default to full transcript dump.

5.8 Audit and observability layer
Kashi needs two distinct audit surfaces.

A. Governance audit
- policy bundle versions
- activation transitions
- reason-coded access logs
- challenge outcomes
- suppression / rollback actions
- admin config changes

B. Security / operations audit
- ingestion failures
- parser errors
- auth anomalies
- protected-route security events
- model boundary violations if any optional model-assisted lane exists later

These surfaces must be permission-separated.

5.9 Pause / rollback / decommission subsystem
This is where most rollout plans stay fake. Kashi should not.

Pause types
1. Soft pause
- stop new ingestion for tenant or meeting class
- keep self-view available for already-processed data if safe
- disable new manager/executive refreshes

2. Governance pause
- immediately disable manager mirror and executive aggregate views
- preserve worker self-view and challenge path
- freeze drill-down except security/legal emergency paths

3. Hard incident pause
- stop ingestion
- disable all non-essential user views
- preserve logs
- route to incident response workflow

Rollback types
1. Detector rollback
- revert tenant to previous detector version / threshold bundle
- mark affected interval as policy-version-changed
- recompute derived metrics if required

2. Policy rollback
- revert to previous approved PolicyBundle
- require reason code and audit entry
- notify affected governance roles

3. Access rollback
- automatically revoke recently expanded role visibility if post-change checks fail

Decommission types
1. Pilot sunset
- stop ingestion on scheduled date
- preserve only data layers justified by published retention schedule
- offer user export for private materials
- remove manager/executive surfaces

2. Trust-failure shutdown
- disable all institutional views
- maintain user-safe access/export window where appropriate
- begin deletion program per policy and legal hold constraints

3. Tenant offboarding
- revoke access
- confirm retention/deletion status by layer
- confirm destruction or expiry of tenant-specific secrets where applicable


6. Trigger framework: when should the system pause, roll back, or decommission?

6.1 Pause triggers
Recommended minimum triggers:
- access-control breach or unauthorized visibility event
- protected private telemetry leak into employer-facing analytics
- unresolved challenge backlog beyond SLA threshold
- transcript/diarization quality falling below support threshold for a material share of pilot meetings
- credible worker trust breakdown signal during pilot review checkpoint
- detection of identity inference risk in small-team aggregate views
- rollout of unsupported meeting class by mistake

6.2 Rollback triggers
- detector update materially increases false positives or complaints
- policy bundle activated without required approvals
- access expansion enabled without matching notice/consultation state
- reason-code enforcement broken
- audit-log visibility to affected individuals not functioning

6.3 Decommission / expansion-stop triggers
- repeated misuse for performance or disciplinary workflows
- representative consultation failure not remediated
- structural inability to maintain anti-retaliation boundary
- unresolved jurisdictional blocker for EU/Germany-style enterprise deployment
- customer insists on unsafe scope expansion (content surveillance, named manager-to-manager comparison, company-wide health bar, etc.)


7. Material-change trigger model

A material change should automatically force re-approval / renewed consultation if it changes any of the following:
- new input substrate
- new meeting classes in scope
- new role access or broadened drill-down
- new retention duration outside approved band
- new detector family
- move from structural-only to hybrid semantic lane
- cross-border data path change
- new downstream use case
- change to notice language affecting protected/private states

Recommended change classes
- Minor: copy clarification, bug fix, no new capability, no power expansion
- Major: any change to inputs, access, retention, use, or analysis semantics
- Emergency: temporary restriction or safety control to reduce risk

Emergency restrictions may ship fast.
Emergency expansions should not.


8. Sequencing rule for first real pilot

Recommended order
1. policy bundle + representative consultation + notice pack finalized
2. State 1 shadow ingestion
3. State 2 worker self-view only
4. challenge/correction rehearsal and anti-retaliation QA
5. manager self-mirror
6. executive aggregate/roster only after suppression, access logging, and trust review checkpoint pass
7. exceptional case workflow only after formal procedure exists

What not to do
- do not start with CEO roster just because it demos better
- do not run a “silent pilot” under ordinary meeting software
- do not treat opt-in checkbox as sufficient legitimacy mechanism
- do not launch manager mirror without protected private states already hardened


9. Acceptance criteria for pilot launch

The project should not call itself rollout-ready unless all of the following are true.

Policy / governance
- In-scope and out-of-scope meeting classes are fixed and encoded
- Notice bundle exists in three layers: policy, pilot, in-product
- Prohibited uses are published and accepted by tenant admins
- Material-change trigger exists and is enforced

Access / privacy
- RBAC matrix is active and tested
- Reason codes are mandatory for non-self-view access
- Access history is visible to affected individuals
- Protected private-state telemetry is segregated from employer-facing analytics
- Small-team anti-inference suppression is active and tested

Challenge / correction
- Transcript challenge path works end-to-end
- Speaker-attribution challenge path works end-to-end
- Confound-marking works and can suppress/deprioritize relevant signals
- Challenge state propagates to downstream views
- SLA and disposition states exist

Operational quality
- State machine transitions are versioned and auditable
- Soft pause, governance pause, and hard incident pause can be executed by runbook
- Detector rollback and policy rollback are tested
- Tenant offboarding / pilot sunset flow is documented and testable

User safety / trust
- Worker self-view launches before manager/executive views
- No employer-visible signal is generated by opening pattern page, vault creation, or draft preparation
- Evidence sharing defaults to minimal package with preview
- Support / escalation pathways are visible without forcing institutional disclosure


10. Priority engineering backlog

P0
- Build PolicyBundle / DeploymentState control plane
- Implement protected-route telemetry segregation
- Implement reason-coded access enforcement
- Implement challenge lifecycle with provisional suppression
- Implement pause / rollback primitives
- Encode meeting scope profiles and exclusion logic

P1
- Access-history panel for affected users
- Share-preview workflow with redaction defaults
- Material-change classification and approval workflow
- Small-team inference test suite
- Notice versioning + just-in-time meeting notice records

P2
- Governance dashboard for pilot-state readiness
- Representative-audit export pack
- Per-tenant rollout checkpoint wizard
- Tenant-facing decommission / sunset assistant


11. Brutal recommendations to the Kashi team

1. Stop treating rollout as mostly messaging.
It is a runtime governance problem.

2. Make “protected private states” a first-class engineering object.
If concern formation leaks, the worker-protective thesis collapses.

3. Build rollback before widening views.
A system that cannot reverse itself safely is not deployment-ready.

4. Treat policy versions like code versions.
Access rights, scope, retention, and notice are part of the executable system.

5. Refuse customer pressure to collapse the sequence.
If they want manager/executive views before worker-safe controls, they are asking to use the product in the most politically dangerous way.

6. Build the audit surface for the affected individual, not just for admins.
Otherwise “auditable” just means the institution audits itself.

7. Use observation-only fallback aggressively.
Unsupported meeting classes should degrade to no-claim mode, not pseudo-confidence.


12. Final answer in one sentence

Kashi should not go live as “careful analytics.” It should go live only as a versioned, stateful, worker-safe rollout system with encoded gates, protected telemetry, challenge propagation, and tested kill/rollback paths.


Source base used for this synthesis

Internal project materials
- Kashi — Progress & Project Overview (2026-04-21)
- Kashi_rollout_research_synthesis
- Kashi_Retaliation_Risk_Research_Memo_2026-04-21_scrubbed
- kashi_labor_politics_union_works_council_memo
- Kashi_Research_Synthesis_Legal_Procedural_Fairness_2026-04-21

Current official / authoritative external anchors checked on 2026-04-21
- European Commission, Navigating the AI Act
- NIST AI RMF Playbook / Govern
- UK ICO, Employee monitoring – is it right for your business?
- MHLW / あかるい職場応援団, Power Harassment in the Workplace
- PPC Japan, Laws and Policies / APPI materials