Kashi backend logic — critical verification and refined suggestion note Version: 2026-04-21 Format intent: project-use txt Purpose: critically verify the current backend-logic direction and refine it into a suggestion-oriented note, not a frozen implementation plan. IMPORTANT FRAMING This note is intentionally not written as: - “the backend plan” - “the fixed architecture” - “the single correct implementation order” It is written as: - suggestion / consideration points - decision options - risk flags - “if you adopt this point, these acceptance criteria should be cleared” That framing matters because the product doctrine is still being built. The team should not get trapped inside one prematurely hardened perspective. ====================================================================== 0. EXECUTIVE VERDICT ====================================================================== Short verdict The current backend direction is viable as a proof-of-mechanism backbone, but it is not yet strong enough to be treated as a settled product architecture. What is already solid - structural-first detection - longitudinal aggregation - review-worthy event objects rather than labels - role-bounded presentation - anti-surveillance instincts - user-protective escalation logic What is still materially weak - ontology contradiction (“metadata only” vs detectors that require transcript interpretation) - missing measurement layer - insufficient meeting-type normalization - weak abstention / uncertainty discipline - under-specified input-quality gating - under-developed anti-gaming logic - incomplete retaliation-safe telemetry separation - insufficient procedural / operational controls after a signal exists Bottom line The core idea works better when treated as: “a restricted evidentiary workflow for contestable review-support signals about repeated interaction asymmetry under uncertainty” and worse when treated as: “a system that detects harm / harassment / abusive intent from meetings” The refined recommendation is therefore: keep the architecture direction, narrow the claims, harden the missing layers, and phrase most additions as gated consideration points with explicit adoption criteria. ====================================================================== 1. WHAT SEEMS DEFENSIBLE ALREADY ====================================================================== 1.1 Structural-first logic is the strongest base The cleanest backend spine is still: meeting ingestion -> feature extraction -> longitudinal aggregation -> review-worthy event construction -> role-bounded surfaces This is consistent with the strongest parts of the current project direction because it keeps the product explainable, traceable, and less vulnerable to “black-box HR AI” critiques. Why this seems right - turn timing, overlap, speaking share, directed interruption, and baseline drift are much more defensible than affect, sentiment, or intent claims - this keeps the system close to “review support” rather than “verdict engine” - structural evidence is more compatible with contestability and bounded retention Refined suggestion Keep the structural core as the default backbone unless later evidence clearly justifies a broader detection layer. If adopted, minimum acceptance criteria - every surfaced claim must trace to meeting IDs, turn IDs, timestamps, and detector reason codes - every surfaced signal must be expressible without moral language - every employer-facing output must be reducible to bounded, contestable evidence objects rather than narrative accusations 1.2 Review-worthy event objects are better than labels This is one of the strongest instincts in the project and should remain central. Good object - review-worthy interaction pattern - repeated asymmetry signal - potential uneven conversational treatment pattern Bad object - harmful manager detected - abuse detected - harassment score - psychological safety score - relationship health score Refined suggestion Treat “event object” and “pattern summary” as the main unit of backend output. Do not let the backend natively emit legal, moral, or psychological verdicts. If adopted, minimum acceptance criteria - backend event schema must separate signal type, confidence/evidence grade, and reviewer interpretation - the system must never require a reviewer to accept the system’s interpretation as final - event objects must support challenge, suppression, or downgrade 1.3 Role-bounded visibility remains directionally correct The mirrors-not-microscopes idea still looks like the right foundation: - individual sees own pattern context - manager sees own mirror - upward views are aggregate-first - deeper access is exception-path only Refined suggestion Treat bounded visibility as architecture, not messaging. If adopted, minimum acceptance criteria - no manager default access to named subordinate telemetry - no casual browsing of raw meeting context by HR / executives - all exceptional drill-downs require reason code, logging, and reviewer pathway - small-team and anti-inference suppression must exist before broader rollout ====================================================================== 2. THE BIGGEST WEAKNESSES THAT STILL NEED TO BE TAKEN SERIOUSLY ====================================================================== 2.1 The ontology contradiction is real and should be explicitly resolved Current tension: the project often sounds like “metadata only / no content”, but several candidate detectors are not truly content-free. Examples of detectors that are not clean metadata-only: - unanswered-question rate when “substantive response” matters - topic-credit ignored-turns - agreement-asymmetry / position-shift logic - directive concentration if linguistic classification is involved This contradiction is not just wording trouble. It changes: - privacy posture - buyer language - review defensibility - procurement/security answers - rollout trust story Refined suggestion Do not keep mixed rhetoric. Choose one of these explicitly: Option A — structural-only MVP Only Tier 1 detectors for employer-facing outputs. Pros: cleanest trust/defensibility story. Cons: narrower signal surface. Option B — honest hybrid MVP Tier 1 structural core plus a constrained small set of transcript-semantic detectors. Pros: broader coverage. Cons: more nuanced governance burden. Suggested current stance For pitch / early product doctrine: structural-only is cleaner. For real product: an honest hybrid may eventually be stronger. But the mixed rhetoric should be removed now. If adopted, minimum acceptance criteria - detector taxonomy must be explicit in docs and code - each detector must be tagged by evidence type and governance burden - employer-facing outputs must clearly distinguish structural vs constrained transcript-semantic basis - no detector should be described as “metadata only” if it depends on semantic interpretation 2.2 The missing measurement layer is the main backend gap The current direction still risks acting like: “we have detectors, therefore we have a valid system” That is not enough. The actual gap is not more detector creativity. It is measurement discipline. The missing pieces are: - baseline stack - evidence grades - abstention rules - input-quality gating - confound handling - comparable-exposure logic - validation plan beyond planted synthetic examples Refined suggestion Create a dedicated measurement layer between raw detector outputs and review-worthy event generation. If adopted, minimum acceptance criteria - no person-level pattern object should be generated without passing measurement-layer rules - evidence grade must be surfaced, not hidden - abstention must be possible - meeting count alone must not be treated as “enough evidence” 2.3 Meeting-type normalization should be treated as validity logic, not optional polish Without meeting-type normalization, one of the easiest attacks against the product remains valid: “your system assumes one normal meeting model across different meeting purposes” That is weak. Problem examples - standup: short updates and fast turns are normal - incident bridge: authority compression and command redirects are normal - design critique: challenge density is normal - 1:1: asymmetry is partly built into the format - training: instructor dominance is often expected - executive review/client meeting: priors are different again Refined suggestion Meeting type should become a first-class input to the interpretation layer. Suggested initial supported categories - weekly sync - standup - design critique / project review Suggested greylist / observation-only categories until calibrated - 1:1 - incident bridge - training - client meeting - exec review - multilingual mixed-format special meetings If adopted, minimum acceptance criteria - every meeting must have either a classified meeting type or a low-confidence / unknown flag - unsupported or low-confidence meeting types must fall back to observation-only or heavily down-ranked interpretation - comparable-baseline logic must be within meeting type, not only across all meetings 2.4 Input reliability is underpowered in the current shape The backend can only be as clean as its input layer. Transcript and diarization errors are not nuisance details. They affect the meaning of the detector outputs themselves. Core fragilities - wrong speaker attribution poisons directional logic - overlap-heavy audio weakens interruption detection - multilingual or L2-heavy speech affects latency and participation interpretation - provider/platform differences are non-trivial - “transcript” is not one uniform object across Zoom / Teams / Meet Refined suggestion Introduce a provider-capability and input-quality layer before inference. Suggested quality dimensions - transcript quality - diarization quality - overlap segmentation quality - language confidence / multilingual flag - recording provenance / edit history - comparable exposure sufficiency If adopted, minimum acceptance criteria - no directional asymmetry output when speaker attribution quality is below threshold - no interruption/chilling interpretation when overlap segmentation is degraded - multilingual / L2-heavy meetings must carry explicit caveat or abstention rules until validated - quality logs must be stored and queryable 2.5 Anti-gaming should be treated as a default design problem, not an edge-case memo If actors learn what is visible, some will improve behavior. Some will improve only the metric. Likely adaptation routes - shift from interruption to agenda control - shift from public pressure to 1:1 or side channels - delegate exclusion downward - become more polite while preserving suppression - optimize around visible metrics while keeping power asymmetry intact Refined suggestion Do not interpret metric improvements as sufficient proof of organizational improvement. If adopted, minimum acceptance criteria - post-deployment monitoring must check for displacement and suspicious cleanliness - evaluation must include anti-gaming scenarios, not just “did the detector fire?” - the system must be able to flag abrupt metric improvement with parallel signal drift elsewhere as “possible adaptation / watch mode” 2.6 Retaliation-safe metadata handling is still too easy to underestimate This is not side-detail. This is a product architecture requirement. Dangerous leak paths - pattern-page visibility - vault creation metadata - draft-state exposure - tiny-team inference - over-sharing on escalation - manager mirror becoming covert evidence accumulation - protected-route telemetry ending up in ordinary business analytics Refined suggestion Treat concern formation itself as protected. Protected private states that should be explicitly modeled - private awareness - concern formation - private evidence retention - selective sharing - formal case handling Suggested rule States 1–3 should not generate employer-visible signals by default. State 4 should require explicit user action. State 5 should require a separately defined institutional procedure. If adopted, minimum acceptance criteria - page opens / confound marking / private drafting must not hit employer-facing analytics - vault existence/activity must be hidden from employer-side users - no employer-visible draft state - anti-inference suppression must exist for tiny teams and narrow-context cases - protected-route logs must be partitioned from general product analytics ====================================================================== 3. REFINED BACKEND SUGGESTION (AS MODULAR CONSIDERATION SET) ====================================================================== This section is not “the plan”. It is a modular design suggestion. 3.1 Module A — ingestion and provenance layer What it is The layer that stores meeting records, turns, participant role metadata, provider source, and provenance / quality information. Why it matters Without provenance and quality, later detector confidence is fake-clean. Suggested fields - org / team / meeting IDs - provider source - transcript source type - diarization confidence - ASR confidence - language flags - role tags if available - transcript edit provenance - external participant flags - meeting-start notice state if relevant If adopted, minimum acceptance criteria - all meeting inputs are provenance-tagged - source/provider differences are not collapsed away - transcript updates or edits are auditable 3.2 Module B — detector engine What it is The low-level event generation layer. Suggested detector taxonomy Tier 1: Structural Examples: - speaking-share inequality - intrusive interruption - response latency asymmetry - dyadic concentration - post-event chilling delta Tier 2: Constrained transcript-semantic Examples: - unanswered-question rate - topic-credit recovery / ignored-turn logic - agreement asymmetry if transcript-based Tier 3: Out of scope / forbidden Examples: - emotion inference - intent detection - voice stress - facial-expression inference - generalized productivity scoring Refined suggestion Keep Tier 1 as the cleanest path to employer-facing live outputs. Treat Tier 2 as explicitly bounded and higher-governance. Treat Tier 3 as refusal doctrine. If adopted, minimum acceptance criteria - every detector is tier-labeled in code and docs - each detector has failure modes and confound notes - no Tier 2 detector is silently represented as purely structural - Tier 3 detectors stay rejected unless doctrine changes explicitly 3.3 Module C — measurement and uncertainty layer What it is The interpretation control layer between detector outputs and review-worthy events. Suggested baseline stack - self-history - within-meeting peer comparison - meeting-type baseline - role baseline - dyad baseline Suggested evidence ladder - Insufficient evidence - Weak pattern - Emerging pattern - Stable pattern Suggested confidence inputs - transcript quality - diarization quality - overlap quality - comparable exposure - detector agreement - confound flags - meeting-type support confidence Suggested abstention rules - insufficient comparable exposure - degraded speaker attribution - heavy overlap / segmentation weakness - unsupported meeting type - major unresolved confound - multilingual/L2-heavy context without validated interpretation support Refined suggestion Operationalize confidence as evidence grade + reason codes + abstention triggers rather than hiding it inside one composite score. If adopted, minimum acceptance criteria - evidence grade must be visible in product and logs - every event object must carry uncertainty notes / reason codes - abstention must suppress or down-rank outputs in weak cases - “meeting count only” must not be the threshold logic 3.4 Module D — review-worthy event layer What it is The layer that packages signals into contestable workflow objects. Suggested event object fields - event ID - affected person / subgroup - counterpart / dyad if relevant - detector family - event type - severity - repetition - directionality - evidence grade - uncertainty / caveat notes - confound flags - trace references - shareability level - review state Refined suggestion Treat event objects as “bounded evidence packets”, not just alert rows. If adopted, minimum acceptance criteria - every event object must be challengeable - every event object must be suppressible or downgradable after review - event objects must support minimal-necessary sharing rather than full transcript dump as default 3.5 Module E — privacy / permissions / anti-retaliation engine What it is The layer that decides who can see what, when, and under what reason code. Suggested principles - aggregate-first - no named subordinate telemetry to managers - drill-down as exceptional pathway - anti-inference protection - protected-route telemetry separation - minimal-necessary evidence sharing Refined suggestion Treat privacy and anti-retaliation not as a policy appendix but as a backend routing system. If adopted, minimum acceptance criteria - access reason codes are mandatory for exceptional views - protected-route telemetry is physically or logically segregated - access history is reviewable by affected users where appropriate - small-team inference risk is actively suppressed, not merely warned about 3.6 Module F — governance / rollout / challenge layer What it is The operational layer after a signal exists. This is the most under-specified part right now. What must eventually exist if this becomes plan-bound - challenge path - transcript / diarization correction path - suppression and override logic - retention under challenge - reviewer responsibility rules - rollback / pause triggers - misuse rules - rollout-control pack Refined suggestion Do not call the backend “ready” if this layer is still vibes. If adopted, minimum acceptance criteria - every consequential output has a reviewer path and challenge route - transcript/speaker correction workflow exists - retention and deletion rules under review/case status are explicit - rollout has go / conditional-go / no-go gates - pause/decommission conditions are defined ====================================================================== 4. ACCEPTANCE CRITERIA SUGGESTIONS BY DECISION AREA ====================================================================== This section is intentionally written as: “if the team adopts this area into the active plan, these are plausible acceptance criteria” 4.1 If “structural-only MVP” is adopted Acceptance criteria - all employer-facing live detectors are Tier 1 structural only - product/deck language removes mixed “metadata only but semantic detector exists” rhetoric - any Tier 2 experimentation is explicitly non-production or user-private / reviewer-bounded - event traceability works without transcript-semantic interpretation 4.2 If “honest hybrid MVP” is adopted Acceptance criteria - Tier 2 detector list is small and explicit - privacy/governance notes distinguish structural and transcript-semantic layers - employer-facing access to transcript text remains tightly bounded - procurement/security docs reflect the more nuanced model/data boundary - rollout docs state what is and is not semantic processing 4.3 If “meeting-type normalization” is adopted Acceptance criteria - meeting type is stored as a first-class field - unsupported types degrade to observation-only - baseline calculations are within meeting type where relevant - reviewer UI shows meeting type and support confidence 4.4 If “evidence grade + abstention” is adopted Acceptance criteria - backend emits evidence grade and reason codes - insufficient-evidence cases can be suppressed - UI does not force a clean interpretation when evidence is weak - pilot materials explain what “insufficient / weak / emerging / stable” mean 4.5 If “input-quality gating” is adopted Acceptance criteria - transcript-quality and diarization-quality logging precede pilot-grade interpretation - low-quality meetings can be excluded or downgraded automatically - provider-specific reliability differences are logged and visible - multilingual / L2 caveats are explicit 4.6 If “anti-retaliation design layer” is adopted Acceptance criteria - page opens, confound marking, and private drafting do not leak to employer-facing surfaces - vault metadata is suppressed - no employer-visible draft state - anti-inference controls exist for tiny teams and narrow contexts - protected-route telemetry is segregated - mirror export and downstream appraisal reuse are blocked 4.7 If “anti-gaming monitoring” is adopted Acceptance criteria - evaluation pack includes adaptation / displacement scenarios - post-deployment monitoring checks for suspicious metric cleanliness - review notes can mark possible displacement into non-measured channels - pilot success is not defined solely by score movement 4.8 If “pilot-readiness gate model” is adopted Acceptance criteria - pilot criteria are explicit - meeting scope and exclusions are explicit - sponsor map and audience split are explicit - worker notice / FAQ / challenge path exist - pause/decommission conditions exist - the pilot is framed as proof of mechanism, not proof of universal validity ====================================================================== 5. RED-TEAM QUESTIONS THE BACKEND SHOULD BE ABLE TO SURVIVE ====================================================================== These are useful as stress-test prompts, not just Q&A. Measurement - Compared to what baseline? - Why does this count as asymmetry rather than role-expected behavior? - How much comparable exposure exists? - Why are you confident this is not just noise? Input - What happens if diarization is wrong? - What happens if two speakers overlap heavily? - What happens in multilingual meetings? - What happens when platform transcript quality changes? Governance - Who can challenge a signal? - What is shown to whom? - What gets logged? - What is deleted when? - What if a user says the transcript or speaker assignment is wrong? Trust / retaliation - Can my manager tell I opened the pattern page? - Can anyone tell I created a vault? - Can small-team context reconstruct my identity? - Does my private exploration become an HR signal? Adversarial - What if behavior becomes more polite but equally suppressive? - What if pressure moves into 1:1s? - What if managers optimize the visible metric only? - What if a “good” pilot merely reflects polite early adopters? If the backend note cannot answer these questions cleanly, it is still too soft. ====================================================================== 6. WHAT SHOULD NOT BE HARD-COMMITTED YET ====================================================================== The following should remain under consideration, not locked: - exact detector menu beyond the structural core - whether the real MVP is structural-only or honest hybrid - whether ally-path is V2 or later - final meeting-type taxonomy breadth - exact thresholds for abstention, confidence, or suppression - which roles get what during early pilots - how much event-context window is shown in different review modes - final retention timing details under challenge/case workflow These are not “unknown because we are lazy”. They are “unknown because they depend on product doctrine, pilot evidence, and governance risk trade-offs”. ====================================================================== 7. WHAT SHOULD PROBABLY BE HARDENED NOW, NOT LATER ====================================================================== These are the few points that seem strong enough to tighten immediately. 1. Fix the content contradiction now. 2. Narrow all rhetoric to asymmetry-under-uncertainty. 3. Add evidence grades and abstention. 4. Treat meeting type as first-class. 5. Add transcript / diarization quality gating. 6. Make protected private states explicit. 7. Separate protected telemetry from business analytics. 8. Keep manager mirror self-only. 9. Treat challenge / correction workflow as part of backend readiness. 10. Split “buyer story” from “worker legitimacy story”. ====================================================================== 8. SUGGESTED FINAL POSITIONING FOR THE BACKEND NOTE ====================================================================== The cleanest serious wording is something like: “Kashi’s backend should be developed as a restricted evidentiary workflow for contestable review-support signals about repeated interaction asymmetry under uncertainty in recorded meetings. The strongest current direction is a structural-first architecture with bounded visibility, abstention under weak evidence, meeting-type-aware interpretation, and explicit protection against retaliation-sensitive metadata leakage. Additional detector breadth or workflow power should be treated as gated considerations rather than assumed defaults.” That wording is less sexy. It is also much harder to tear apart. ====================================================================== 9. SOURCE NOTE ====================================================================== This note was refined against: - current Kashi internal research and synthesis memos on measurement, legal/procedural fairness, trust, retaliation, rollout, ally-path, and overall research synthesis - current official/primary external materials checked on 2026-04-21, including European Commission AI Act pages / FAQ, EUR-Lex AI Act text, ICO workplace monitoring guidance, EDPB consent guidance / SME guide, NIST 2026 monitoring material, and official support pages for Google Meet, Microsoft Teams, and Zoom transcript/transcription behavior This note is strategy / product / architecture guidance, not legal advice.