KASHI — TECHNICAL RESEARCH MEMO Contestability / Correction-Workflow Perspective Prepared for: engineering / product / governance Date: 2026-04-21 Purpose Turn “contestability” into concrete system behavior for Kashi. This is not a values essay. It is a technical architecture and workflow memo for how a recorded-meeting analytics system must behave once a signal exists and a user says: “this is wrong”, “this is incomplete”, or “this is unfairly framed”. Bottom line If Kashi cannot be challenged at the object level, input level, and aggregation level, it is not governance infrastructure. It is a confidence theater dashboard. The current Kashi materials are already strong on deterministic detectors, review-worthy events, RBAC, audit trails, employee-first visibility, and anti-retaliation instincts. The main gap is what happens after the system is wrong, incomplete, or disputed. Internal Kashi research already says the procedural gap is the real weakness, not the detector idea itself. External guidance reinforces the same point: systems handling person-linked AI-supported outcomes need rectification paths, human review, explanation, and meaningful challenge rather than token review. Core judgment: 1. Kashi needs a formal contestability state machine. 2. Disputes must exist at multiple layers, not only “appeal the final score”. 3. Successful disputes must propagate downstream. Otherwise correction is fake. 4. Protected private use states must stay private until explicit user sharing or a separately defined institutional threshold workflow. 5. Review must be meaningful: a reviewer must have authority to reverse, suppress, narrow, or recompute an output. -------------------------------------------------------------------------------- 1. Why this matters for Kashi specifically -------------------------------------------------------------------------------- Kashi currently positions itself as a governance system built on deterministic structural signals, review-worthy events instead of harassment labels, and role-bounded visibility. The progress deck says detection is threshold-triggered, human-approved, and never auto-actioned. It also says every review-worthy event traces to turn IDs and rule triggers, and that audit trails, k-anonymity, and role controls are first-class. Good. But that only covers explainability in the forward direction. It does not yet define challengeability in the reverse direction. That is the missing piece. The legal/procedural-fairness synthesis is explicit: the main unresolved weakness is procedural, not algorithmic; the materials still under-specify who can contest, how transcript/diarization errors are handled, how much context is shown, when raw data is preserved under challenge, what reviewers can override, and what downstream uses are blocked. The same memo says Kashi should be framed as “a controlled evidentiary workflow for contestable structural interaction signals in recorded meetings,” which is basically the right doctrine for this entire workstream. The retaliation memo deepens the constraint: private awareness, concern formation, and private evidence retention must not create employer-visible signals before explicit user sharing or a separately defined threshold process. That means the correction path itself must be privacy-safe. If opening a dispute leaks concern formation to the wrong actors, the system poisons its own use. Critical implication: Kashi’s contestability workflow is not just “support tickets for analytics”. It is part of the product’s anti-retaliation and trust architecture. -------------------------------------------------------------------------------- 2. What must be contestable -------------------------------------------------------------------------------- Do not model contestability as one generic “this alert is wrong” button. That is too shallow. Kashi needs dispute objects at six distinct layers. Layer A — Input integrity What can be wrong: - transcript text - timestamps - missing turns - speaker attribution / diarization - meeting metadata - meeting-type classification - role labels (chair, facilitator, presenter, IC, trainer) - language / multilingual handling flags Why this matters: If the input layer is wrong, downstream correctness is already poisoned. A user must be able to say “that wasn’t me”, “the transcript dropped the overlap”, “this was a client call”, or “I was the presenter / facilitator; compare me differently”. Required system behavior: A successful Layer A dispute invalidates dependent features and must trigger recomputation. Layer B — Feature extraction What can be wrong: - interruption event detection - latency measurement - speaking-share segmentation - question-response linkage - similarity / topic-credit linkage - agreement-shift construction - meeting window selection - dyad assignment Why this matters: Even with accurate transcript + speaker identity, the detector may have mis-constructed the event. Required system behavior: The system must store derived feature objects explicitly, not only aggregate outputs, so that a reviewer can inspect “why this event existed”. Layer C — Interpretation / event construction What can be wrong: - severity score - repetition logic - directionality logic - confidence weighting - whether the feature bundle should have become a review-worthy event at all - whether the event belongs in observation-only mode instead of risk interpretation Why this matters: Kashi’s own design already says unsupported or low-confidence meeting types should fall back to observational mode. If that rule fails, the dispute is not about raw data but about over-interpretation. Required system behavior: A reviewer must be able to downgrade an event from “review-worthy” to “observational only”, not just edit a note. Layer D — Summary wording / explanation What can be wrong: - wording implies blame or intent - summary overstates confidence - context caveats are omitted - confounds are not represented - the explanation window is too narrow - the language is misleading even if the math is correct Why this matters: A technically correct signal can still be procedurally unfair if the wording is loaded or partial. Required system behavior: Summary text must be versioned separately from the underlying metric and event object. Layer E — Visibility / routing / disposition What can be wrong: - wrong audience saw it - event should have stayed private - escalation package was too broad - the issue was closed without enough review - manager, HR, or investigator routing was inappropriate - draft state appeared in an employer queue too early Why this matters: Contestability is not only about mathematical truth. It is also about whether the system routed and exposed the object correctly. Required system behavior: Visibility decisions and routing decisions need their own audit trail and override capability. Layer F — Longitudinal aggregation What can be wrong: - disputed event still contributes to 30/90/180-day metrics - corrected speaker identity still leaves old dyad trends intact - event was suppressed at item level but still affects team trend, heatmap, or executive aggregate - old summary survives in cached dashboards after correction Why this matters: If the system “corrects” the local object but leaves the trendline dirty, correction is fake. Required system behavior: Successful disputes must propagate downstream according to dependency rules. -------------------------------------------------------------------------------- 3. Core architecture principle: immutable evidence, mutable interpretation -------------------------------------------------------------------------------- Kashi should not “overwrite history” in the naive sense. That creates a second integrity problem. But it also cannot leave bad derived outputs alive. The right pattern is: 1. Immutable original ingest record 2. Versioned derived artifacts 3. Explicit dispute + review objects 4. Recomputation pipeline with dependency invalidation 5. Current effective view + historical audit view Translated into system design: - Preserve the original imported transcript / metadata blob as source_version_0. - Do not silently edit source_version_0. - Create correction patches / adjudicated overlays referencing the original object. - Recompute derived features and event objects into new versions. - Mark older versions as superseded, not active. - User-facing and institutional-facing dashboards read only the current effective version. - Audit view can see historical versions and why they changed, but only with proper role controls. This gives Kashi four things at once: - traceability - reversibility - fair correction - non-destructive audit history -------------------------------------------------------------------------------- 4. Required contestability state machine -------------------------------------------------------------------------------- At minimum, every disputable object needs the following state machine. DRAFT User is preparing a dispute or privately reviewing the item. Visibility rule: private to the user only. This state must not create employer-visible signals. SUBMITTED User has explicitly submitted a dispute. Visibility rule: visible only to the minimum review channel required by policy. Not visible to managers by default. TRIAGED System / reviewer classifies the dispute type: - input error - feature-construction error - interpretation error - wording error - visibility/routing error - aggregation error - policy challenge / threshold governance issue UNDER_REVIEW Human reviewer is actively evaluating. If needed, freeze downstream use for affected objects while review is open. RESOLVED_NO_CHANGE Review found no change needed. Keep explanation and decision record. RESOLVED_CORRECTED Underlying data / feature / event / wording corrected. Trigger recomputation and downstream propagation. RESOLVED_SUPPRESSED Item remains historically recorded but is suppressed from active dashboards and excluded from specified downstream aggregates. RESOLVED_PARTIAL Part of the dispute succeeded. Example: wording changed and visibility narrowed, but base event remains. ESCALATED_GOVERNANCE Used when the dispute points to a policy-level issue: - detector threshold itself is bad - meeting-type prior is unsupported - role taxonomy is broken - multilingual conditions are inadequately handled This is not a case-resolution state only; it should open product/governance review. WITHDRAWN User withdrew the dispute before resolution. Historical record stays, but downstream freeze ends if safe. Important rule: Open disputes on material person-level objects should create a “restricted downstream use” flag until resolved. Otherwise a contested object can keep traveling while the challenge is pending. -------------------------------------------------------------------------------- 5. Who can dispute what -------------------------------------------------------------------------------- Employee / affected individual Can dispute: - transcript accuracy - speaker attribution - missing context - meeting type / role entitlement - summary wording - visibility / routing - disposition - inclusion in longitudinal trend - over-sharing on escalation Manager Can dispute: - self-view event construction - meeting type - role entitlement - wording - detector misfire tied to facilitation / chair duty But manager must not gain subordinate-specific visibility through the act of disputing. Reviewer / investigator / ombuds / compliance role Can: - request supplemental context - narrow or widen review window subject to policy - correct event object status - apply suppression - trigger recompute - create a governance-escalation ticket System admin Should not adjudicate substantive people disputes by default. System admin is for reliability / technical operations unless separately granted governance authority. Do not collapse admin power and reviewer power into one role. -------------------------------------------------------------------------------- 6. Required data model additions -------------------------------------------------------------------------------- Kashi’s current stack needs explicit first-class tables / objects for contestability. Example model: 1. disputable_object Fields: - object_id - object_type (transcript_turn, speaker_assignment, detector_feature, review_event, summary_block, routing_decision, aggregation_slice) - source_meeting_id - source_version_id - current_effective_version_id - lineage_parent_ids - visibility_class - downstream_dependency_count 2. dispute_ticket Fields: - dispute_id - opened_by_user_id - opened_at - privacy_class - dispute_type - target_object_ids[] - reason_code[] - free_text_explanation - requested_remedy[] (correct_text, reassign_speaker, add_context, downgrade_to_observation, suppress_from_aggregate, rewrite_summary, narrow_visibility, reopen_disposition, etc.) - status - review_channel - due_at - freeze_policy 3. dispute_evidence Fields: - evidence_id - dispute_id - evidence_type (user annotation, alternate transcript snippet, meeting metadata, role clarification, confound note, external supporting doc) - encrypted_blob / secure reference 4. review_decision Fields: - decision_id - dispute_id - reviewer_id - decision_type (no_change, corrected, suppressed, partial, escalated_governance) - rationale - confidence - created_at 5. correction_patch Fields: - patch_id - target_object_id - old_value_ref - new_value_ref - changed_by - effective_from - reason_code - linked_dispute_id 6. recompute_job Fields: - recompute_job_id - trigger_type (correction, suppression, meeting_type_change, role_change, threshold_change) - affected_object_ids[] - affected_time_windows[] - status - completed_at 7. aggregation_exclusion Fields: - exclusion_id - object_id - exclusion_scope (local_event_only, person_window, dyad_window, team_window, exec_aggregate) - start_at - end_at / indefinite - reason 8. access_history Fields: - access_id - object_id - viewer_id - viewer_role - reason_code - access_time - case_id / dispute_id if applicable -------------------------------------------------------------------------------- 7. Downstream propagation rules -------------------------------------------------------------------------------- The user explicitly asked the hardest question: Does a successful dispute suppress downstream aggregation too? Answer: Yes, if the disputed element contributed to downstream interpretation. But the suppression model must be typed, not blanket. Rule set: Type 1 — Input correction Examples: - wrong speaker label - missed turn - wrong meeting type - incorrect role assignment - transcript error that changes detector behavior Effect: - invalidate dependent features - invalidate review-worthy events built from them - recompute person, dyad, team windows affected by the object - supersede old aggregates - keep old versions only in restricted audit history This is not optional. Anything else is mathematically dishonest. Type 2 — Feature-construction correction Examples: - false interruption - wrong question-response linkage - wrong similarity edge for topic-credit detection Effect: Same as Type 1 for all dependent event objects and aggregates. Type 3 — Interpretation correction Examples: - event should have been observation-only - confidence was too low - unsupported meeting type should not have scored - facilitation behavior was legitimate Effect: - suppress event from active risk counts - optionally keep deterministic observation visible in a reduced/private form - exclude from escalation thresholds and role-up dashboards as defined Type 4 — Summary/routing correction Examples: - wording unfair - wrong recipient - package too broad Effect: - does not necessarily change raw metric - must change the visible object and/or visibility scope - may require retraction notice if the object was already exposed to a wrong audience Type 5 — Policy-level threshold challenge Examples: - global threshold too aggressive for a certain meeting class - multilingual meetings not calibrated - a detector family is overcalling Effect: - do not silently “fix” one case and pretend the model is fine - create governance issue - optionally apply temporary local suppression to similar outputs until policy review completes Design rule: No contested object should continue feeding executive or HR aggregates as if clean. At minimum, open or upheld disputes should mark affected aggregate slices as one of: - pending review - corrected - partially suppressed - excluded from current rollup -------------------------------------------------------------------------------- 8. Review windows, freezing, and retention -------------------------------------------------------------------------------- Kashi already has a four-tier retention model in the progress materials: raw 14 days, analytics 24 months, review-worthy events 12 months, legal-hold extended. Contestability changes how that retention should behave. Required rules: 1. Dispute hold If a dispute is open on a raw-data-dependent object and raw retention would otherwise expire, the minimum required source material must be preserved until the dispute is resolved. Otherwise the system destroys the basis for challenge. 2. Minimal preservation Do not freeze the whole meeting forever by default. Freeze only the minimum needed slice: - disputed turns - linked detector inputs - linked event objects - linked summary versions - linked routing decisions 3. Restricted-use freeze While a material dispute is open, the affected object should be restricted from: - new escalation packages - threshold-triggered institutional actions - management-facing summaries unless there is a documented exception path. 4. View retraction rule If a visible summary is corrected materially after exposure to a reviewer, manager, or compliance user, the system should create a retraction/update notice in the access trail: “This object was later corrected/suppressed; prior interpretation should not be relied upon.” -------------------------------------------------------------------------------- 9. Meaningful human review: what reviewers must actually be able to do -------------------------------------------------------------------------------- External guidance is clear on this point: meaningful human review is not “a human looked at it”. The reviewer must be able to: - inspect inputs and explanation objects - understand model/feature assumptions - receive user-provided context - override or reverse the output - change routing / visibility - trigger recomputation - record rationale For Kashi, that means the reviewer console needs at least: 1. explanation graph - source turns - speaker assignments - detector triggers - confidence objects - meeting-type + role context 2. user-supplied challenge narrative 3. confound panel - language conditions - role conditions - meeting type - special facilitation context 4. action panel - no change - correct input - downgrade to observation - suppress - rewrite summary - narrow visibility - trigger governance review 5. propagation preview - which windows / dashboards / aggregates will change if resolved this way If the reviewer cannot see the propagation impact, they are adjudicating blind. -------------------------------------------------------------------------------- 10. Privacy-safe contestability rules -------------------------------------------------------------------------------- This part is non-negotiable for Kashi because contestability itself can become a retaliation vector. Protected states that must remain private by default: - opening own pattern page - repeated self-review - reading support content - marking confounds - starting a draft dispute - enabling evidence vault - storing private encrypted evidence - previewing a share package System rules: 1. States above must not notify manager, HR, or executive surfaces. 2. Security telemetry for these actions must be technically segregated from business analytics. 3. No employer-visible draft state. 4. No manager inference from team-size/timing. 5. No vault metadata leakage. 6. No subordinate-specific visibility granted through a manager dispute flow. 7. Default escalation package = minimum necessary event object, not full transcript dump. -------------------------------------------------------------------------------- 11. Recommended API / service behavior -------------------------------------------------------------------------------- Representative interface sketch: POST /disputes Creates private draft or submitted dispute ticket. POST /disputes/{id}/submit Explicit transition from DRAFT to SUBMITTED. This boundary matters because draft state must stay private. GET /objects/{id}/explanation Returns structured explanation graph for challengeable object. Must be role-bounded. POST /disputes/{id}/evidence Attach encrypted or role-bounded supporting evidence. POST /disputes/{id}/triage Reviewer-only. POST /disputes/{id}/resolve Decision payload: - decision_type - correction_patch - suppression_scope - visibility_override - recompute_required - rationale POST /recompute-jobs System-internal or reviewer-triggered. GET /access-history/{object_id} Affected individual should be able to see exceptional accesses where policy allows. Important engineering rule: The frontend should not be the source of truth for dispute privacy semantics. Protected/private state must be enforced server-side in authorization and event pipelines. -------------------------------------------------------------------------------- 12. Acceptance criteria the dev team should actually clear -------------------------------------------------------------------------------- A. Object-level explanation - Every review-worthy event can be traced to source turns, speaker IDs, thresholds, and confidence objects. B. Input correction propagation - Correcting a speaker label or meeting type causes affected features, events, and aggregates to recompute. C. Pending-dispute freeze - Contested person-level objects are prevented from silently feeding downstream institutional workflows while under review. D. Summary versioning - Summary wording can be revised without destroying underlying historical lineage. E. Private draft protection - Starting a dispute or vault does not create employer-visible analytics, queues, or notifications. F. Anti-inference controls - Small-team or narrow-window cases are suppressed/batched/redacted enough that a manager cannot trivially infer who triggered review. G. Reviewer power is real - Reviewer can reverse, suppress, downgrade, rewrite, narrow visibility, and trigger recompute. H. Retention under challenge - Minimum required source material is preserved through dispute resolution even if normal raw retention would expire. I. Access traceability - Exceptional drill-down and post-correction retraction history are recorded and visible to the affected individual where policy says they should be. J. Governance escalation path - Policy-level disputes can open governance review tickets rather than forcing case reviewers to fake a case-only fix. -------------------------------------------------------------------------------- 13. MVP recommendation -------------------------------------------------------------------------------- Do not try to launch “full procedural justice OS” on day one. But do not ship a pseudo-appeal button either. MVP-contestable scope: - transcript / speaker attribution disputes - meeting type / role disputes - summary wording disputes - observation-only downgrade - suppression from downstream person/dyad/team rollups - private draft state - recomputation for corrected inputs - access-history for exceptional drill-down Can wait until later: - cross-case governance analytics on dispute patterns - advanced external evidence intake - bulk policy remediations - semi-automated reviewer recommendation models But one thing must not wait: successful disputes must propagate downstream. -------------------------------------------------------------------------------- 14. Critical project judgments -------------------------------------------------------------------------------- 1. Kashi should stop thinking of contestability as a legal appendix. It is a product subsystem. 2. “Human-approved” is too vague unless reviewer powers and override semantics are explicit. 3. “Audit trail” is not enough; the system needs correction lineage + recompute lineage. 4. “No auto-action” does not solve fairness if contaminated aggregates survive after correction. 5. “Private employee lane” only works if draft challenge behavior and evidence retention are invisible to employer-side users by default. 6. If Kashi keeps the current architecture but adds no dispute state machine, critics will be right to say the platform is explainable but not challengeable. -------------------------------------------------------------------------------- 15. Sources used -------------------------------------------------------------------------------- Internal Kashi materials - Kashi — Research Synthesis: Legal Defensibility, Procedural Fairness, and Governance Design (2026-04-21) - Kashi — Retaliation-Risk Research Memo (2026-04-21) - Kashi — Progress & Project Overview (2026-04-21) - Kashi — Meeting-Type Normalization Research Memo (2026-04-21) - Kashi — Procurement / Security-Buyer Readiness Memo (2026-04-21) - Kashi manager adoption research memo (2026-04-21) Official / external guidance used for constraint-checking - European Commission / AI Act Service Desk FAQ - European Commission digital strategy FAQ on the AI Act - European Data Protection Board SME guide on data subject rights - ICO guidance on AI and data protection / individual rights in AI systems - ICO explanation guidance for AI-assisted decisions - ICO worker monitoring guidance / news summary - ICO DPIA guidance - NIST AI RMF 1.0 and NIST AI RMF Playbook End of memo.