KASHI — REFINED TECH / GOVERNANCE CONSIDERATION REGISTER
Project-use draft for developers and planners
Date: 2026-04-21
Format goal: suggestion set + decision register + acceptance-criteria notes
Status: critically refined from earlier architecture map; not a fixed implementation plan

======================================================================
0. HOW TO READ THIS FILE
======================================================================

This is NOT a build order and NOT a rigid target architecture.

It is a refined consideration map for people building the plan right now.

Use it like this:
- If a point changes what Kashi is allowed to claim, how the product will be perceived, or whether the system remains internally coherent, treat it as an architecture / doctrine decision.
- If a point only improves robustness, buyer-readiness, or political survivability later, treat it as a deployment-hardening consideration, not necessarily a Day-1 requirement.
- If a point is adopted into the plan, the acceptance criteria under that point are the minimum bar that should be cleared.

This file intentionally separates:
1) what appears genuinely core after verification,
2) what is conditional on Kashi’s chosen claim set,
3) what is likely later-stage but still important.

======================================================================
1. CRITICAL VERIFICATION RESULT — WHAT GOT TIGHTENED
======================================================================

After pressure-testing the earlier architecture map against the Kashi memos and current official-source checks, the main corrections are:

1.1 Kashi cannot honestly be described as “just an AI detector dashboard.”
It is at minimum:
- an ingestion / normalization system,
- a measurement system,
- a privacy / access-control system,
- a governance workflow system,
- and, if sold to companies, an assurance / rollout system.

1.2 Some earlier points were too easy to hear as “must build all of this now.”
That is not quite right.
The more accurate framing is:
- some points are required if Kashi wants to make certain claims safely,
- some points are required for a serious pilot,
- some points are mainly enterprise-hardening.

1.3 The biggest architectural fork remains real.
The internal materials still show tension between:
- “metadata only / no content”
and
- detectors that appear to require transcript-semantic interpretation.
This is not cosmetic. It must be resolved explicitly.

1.4 The strongest refined posture is:
Kashi estimates repeated interaction asymmetry under uncertainty, within comparable meeting contexts, for review support.
It should NOT present itself as directly detecting harm, harassment, abusive intent, or legal truth.

1.5 “Not monitoring” is still too absolute.
A narrower and more stable line is:
Kashi should not be framed as a general surveillance or performance-monitoring system.
It may still be experienced as a tightly bounded workplace interaction-monitoring system, so the real defense must come from constrained visibility, anti-misuse design, and procedure.

1.6 The anti-retaliation problem is deeper than content confidentiality.
The retaliation memo is right: metadata and workflow-state leakage are core product risks.
If the system protects content but leaks private awareness, vault creation, draft states, or tiny-team inference, the employee-first thesis collapses.

1.7 NIST / current official governance guidance supports using risk-management structure, but not as a checklist.
That matters because a lot of people instinctively turn these topics into “compliance box lists.”
That is the wrong mode. The AI RMF Playbook itself says it is voluntary and not a checklist or ordered set of steps.

======================================================================
2. STRATEGIC DOCTRINE DECISIONS TO SETTLE BEFORE ARCHITECTURE HARDENS
======================================================================

These are not code-level details. They determine what later code is even coherent.

----------------------------------------------------------------------
2.1 TARGET CONSTRUCT DECISION
----------------------------------------------------------------------

Question:
What exactly is Kashi trying to estimate?

Recommended refined answer:
Kashi estimates repeated interaction asymmetry under uncertainty, within comparable meeting contexts.

Why this matters:
If the system is described as estimating “harm,” “harassment,” “abuse,” “intent,” or “illegal conduct,” the product becomes easier to attack epistemically, legally, and politically.
The measurement memo strongly supports the narrower claim.

If adopted into the plan, minimum acceptance criteria:
- product and technical docs never describe outputs as findings of harm or harassment,
- UI labels use “signal,” “pattern,” “review-support,” “provisional,” or equivalent language,
- any composite score is paired with evidence grade / caveat / abstention logic,
- the pilot is described as proof of mechanism and governance usability, not proof of universal validity.

Common self-own:
Saying “the pattern is the harm.”
Refined replacement:
“The pattern may provide evidence consistent with uneven conversational treatment over time and may justify human review.”

Priority:
P0 doctrine / architecture

----------------------------------------------------------------------
2.2 STRUCTURAL-ONLY MVP VS HONEST HYBRID MVP
----------------------------------------------------------------------

Question:
Is Kashi genuinely structural-only, or does it include constrained transcript-semantic detectors?

Why this matters:
This affects:
- detector design,
- privacy claims,
- legal posture,
- procurement language,
- data-boundary documentation,
- and internal credibility.

Refined options:

Option A — Structural-only MVP
Use only timing / speaker / adjacency / overlap / participation / graph-derived signals.

Option B — Honest hybrid MVP
Core live path stays rule-based and explainable, but selected constrained transcript-semantic detectors are allowed.

Refined judgment after verification:
For a hackathon deck, structural-only is cleaner.
For a real product, honest hybrid may eventually be stronger.
But the mixed rhetoric cannot stay.

If Option A is adopted, minimum acceptance criteria:
- topic-credit / unanswered-substance / agreement-shift logic is removed or redefined structurally,
- all shipped detectors can be defended as not requiring transcript-semantic interpretation,
- “metadata only” language remains true in practice.

If Option B is adopted, minimum acceptance criteria:
- detector taxonomy is explicit (structural / constrained semantic / forbidden),
- every semantic detector is documented and bounded,
- no employer browsing of raw semantic interpretation is introduced by accident,
- model/data boundary memo exists,
- “core detection is structural-first” or equivalent wording replaces absolutist “metadata only” phrasing.

Common self-own:
Quietly shipping semantic interpretation while still saying “none read meeting content.”

Priority:
P0 architecture / product honesty

----------------------------------------------------------------------
2.3 ROLE OF ABSTENTION
----------------------------------------------------------------------

Question:
Is the system allowed to say “not enough basis” or is it forced to always score?

Recommended answer:
It must be allowed to abstain.

Why this matters:
The measurement memo is explicit that forced inference in weak cases is bad measurement practice.
Abstention is a trust mechanism, not a weakness.

If adopted into the plan, minimum acceptance criteria:
- person-level outputs can be suppressed for thin comparable exposure,
- low speaker-attribution quality blocks directional claims,
- overlap-heavy degraded audio blocks interruption/chilling interpretation,
- multilingual or L2-heavy sessions can trigger strong caveat / abstention,
- user-marked major confounds can down-rank or defer interpretation.

Priority:
P0 measurement layer

======================================================================
3. CORE ANALYSIS SYSTEM — CONSIDERATION POINTS
======================================================================

These are the main technical domains that probably belong in any serious plan, though not all at the same delivery stage.

----------------------------------------------------------------------
3.1 SOURCE INGESTION / CAPTURE
----------------------------------------------------------------------

Consideration:
Kashi needs a canonical source-capture layer, not ad hoc per-platform plumbing.

What this actually includes:
- platform integration (Zoom / Teams / Meet / uploads),
- transcript pull,
- speaker attribution,
- timestamps,
- meeting metadata,
- participant roster,
- organizer / host info,
- external participant flag,
- ingestion provenance,
- retry / dedupe behavior.

Critical verification:
This still stands.
The project materials already assume meeting transcripts, speaker attribution, timestamps, and meeting metadata as primary inputs.

What should be decided:
- Which sources are first-class vs secondary?
- What counts as an authoritative meeting record?
- How are identities reconciled across platforms?
- When is ingestion triggered?
- How are transcript revisions handled?
- What happens with partial or failed pulls?

If taken into the plan, minimum acceptance criteria:
- replay-safe ingestion,
- source provenance stored per meeting,
- canonical meeting object exists,
- duplicate pull handling exists,
- partial ingestion cannot silently produce full-confidence downstream metrics.

Likely deferability:
Cannot be deferred if Kashi analyzes real meetings.
Can be simplified for prototype, but not skipped.

----------------------------------------------------------------------
3.2 NORMALIZATION / PREPROCESSING
----------------------------------------------------------------------

Consideration:
Raw platform transcripts are not analysis-ready.

Needed capabilities:
- parsing different transcript/file formats,
- canonical turn segmentation,
- speaker mapping,
- timestamp normalization,
- raw-vs-normalized lineage,
- preprocessing versioning.

Critical verification:
Still core.
Without this, downstream metrics become unstable and un-auditable.

If taken into the plan, minimum acceptance criteria:
- raw source preserved or versioned,
- normalized output is deterministic,
- every downstream event can reference normalized turn IDs,
- preprocessing version stored on derived outputs.

Common self-own:
Treating “transcript arrived” as equivalent to “turn structure is trustworthy.”

----------------------------------------------------------------------
3.3 INPUT-QUALITY / ASR / DIARIZATION GATING
----------------------------------------------------------------------

Consideration:
Kashi may partly measure who the speech system fails on.
This is not a side note.

Needed quality variables:
- transcript confidence,
- diarization confidence,
- overlap quality,
- mixed-language likelihood,
- code-switching likelihood,
- sparse-audio / noisy-audio flag,
- segmentation integrity.

Critical verification:
This point survives strongly.
The measurement memo explicitly says input quality is part of the construct-validity problem.

If taken into the plan, minimum acceptance criteria:
- per-meeting quality bundle exists,
- detector families declare input prerequisites,
- poor-quality meetings can be down-ranked or blocked,
- UI can explain quality-based suppression,
- pilot analytics include blocked/down-ranked rates.

Common self-own:
“Confidence” hidden inside a score formula with no visible basis.

Priority:
P0 if Kashi claims meaningful review support

----------------------------------------------------------------------
3.4 DETECTOR ENGINE
----------------------------------------------------------------------

Consideration:
Each detector must be more than a number generator.

What a real detector spec needs:
- formal input requirements,
- calculation rule,
- quality prerequisites,
- meeting-type behavior,
- evidence references,
- caveat codes,
- versioning,
- abstention interaction.

Critical verification:
Still core, but needs one refinement:
Detector implementation is only “done” if traceability and caveat behavior exist too.

If taken into the plan, minimum acceptance criteria:
- each detector has a written spec,
- each output references evidence turn IDs or equivalent,
- each detector has versioning,
- unsupported contexts lead to suppression / observation-only behavior.

Common self-own:
“Explainable” claimed while thresholds, prerequisites, or evidence references are hidden.

----------------------------------------------------------------------
3.5 MEASUREMENT LAYER (SEPARATE FROM DETECTORS)
----------------------------------------------------------------------

Consideration:
Detectors are not the same thing as measurement.

Refined required components:
- baseline stack,
- evidence grade ladder,
- confidence inputs,
- abstention logic,
- reason codes,
- confound handling,
- decision engine for what surfaces are allowed to show what.

Critical verification:
This point becomes even stronger after review.
The measurement memo explicitly says the most important technical addition is the measurement layer, not another detector.

If taken into the plan, minimum acceptance criteria:
- baseline stack implemented or consciously simplified,
- evidence grades visible,
- confidence basis defined,
- person-level surfaces can abstain,
- reason codes are stored and inspectable.

Priority:
P0 if Kashi wants to sound scientifically serious

----------------------------------------------------------------------
3.6 BASELINE STACK
----------------------------------------------------------------------

Consideration:
There is no single normal meeting baseline.

Refined baseline stack:
- self-history,
- within-meeting peers,
- meeting-type baseline,
- role baseline,
- dyad baseline.

Critical verification:
Still valid.
The memos strongly support this stack and specifically warn against fantasy universal baselines.

If taken into the plan, minimum acceptance criteria:
- at least self-history + within-meeting + one contextual layer exist,
- baseline source is recorded in interpretation,
- no cross-context comparison is silently presented as universal truth.

Potential phased approach:
- MVP: self-history + within-meeting + limited meeting-type handling
- later: fuller role/dyad calibration

----------------------------------------------------------------------
3.7 MEETING-TYPE NORMALIZATION
----------------------------------------------------------------------

Consideration:
A standup, incident bridge, design critique, training session, and 1:1 are not behaviorally interchangeable.

Critical verification:
Still strongly valid.
Meeting type is part of the validity model, not a UI filter.

Refined practical implication:
Do not assume all meeting types need full scoring from day one.

Suggested posture:
- define supported scoreable types,
- define observation-only / greylist types,
- define fallback handling when meeting type is unknown.

If taken into the plan, minimum acceptance criteria:
- meeting_type exists as a first-class field,
- policy registry exists for supported / greylisted / unsupported types,
- unsupported or low-confidence types do not silently generate governance-grade interpretation,
- meeting-type policy version is stored.

Common self-own:
One “weekly sync prior” applied to every meeting in the company.

----------------------------------------------------------------------
3.8 MULTILINGUAL / CROSS-CULTURAL CALIBRATION
----------------------------------------------------------------------

Consideration:
Language regime is not just localization.
It changes ASR quality, pause interpretation, latency interpretation, and fairness.

Critical verification:
Still valid, but should be phrased as architecture-readiness, not immediate pan-regional scope pressure.

Refined posture:
- go-to-market can remain Japan-first,
- architecture should preserve room for locale packs and language-aware quality gating,
- unsupported multilingual contexts should be caveated, down-ranked, or blocked rather than overinterpreted.

If taken into the plan, minimum acceptance criteria:
- language / mixed-language state is stored,
- baseline logic can at least distinguish materially different language regimes,
- unsupported language conditions do not silently produce full-confidence interpretation.

Potential overreach to avoid:
Claiming East Asia support because upstream platforms support some languages.
Platform support is real, but uneven and feature-specific.

======================================================================
4. TRUST / GOVERNANCE SYSTEM — CONSIDERATION POINTS
======================================================================

This ring is not “ethics garnish.” It is part of product legitimacy.

----------------------------------------------------------------------
4.1 RBAC / CONSTRAINED VISIBILITY
----------------------------------------------------------------------

Consideration:
Kashi’s legitimacy depends on disciplined non-seeing.

Refined role surfaces to treat separately:
- worker self-view,
- manager self-mirror,
- governance reviewer,
- HR / compliance reviewer,
- executive aggregate viewer,
- support / security admin,
- break-glass admin.

Critical verification:
Still absolutely core.
The trust and labor memos support constrained visibility as part of product doctrine.

If taken into the plan, minimum acceptance criteria:
- manager cannot casually browse named subordinate behavioral histories by default,
- executive views are aggregate-first with thresholding,
- exceptional drill-down requires reason code + logging,
- routes and fields are role-scoped, not merely page-scoped.

Common self-own:
Thinking “we have login roles” equals “we have a real visibility model.”

----------------------------------------------------------------------
4.2 PROTECTED PRIVATE STATES / ANTI-RETALIATION DESIGN
----------------------------------------------------------------------

Consideration:
Private awareness, concern formation, and private evidence retention must not create employer-visible signals by default.

Refined protected state set:
- private awareness,
- concern formation,
- private evidence retention,
- selective sharing,
- formal case handling.

Critical verification:
This point is even stronger after review.
It is one of the sharpest project-specific requirements surfaced in the memos.

If taken into the plan, minimum acceptance criteria:
- opening one’s own pattern page creates no employer-visible business signal,
- vault existence / activity metadata is hidden from employer-side users,
- draft concern/report objects stay private until explicit share or independent threshold procedure,
- anti-inference measures exist for tiny-team cases,
- sharing flow supports minimum-necessary package selection.

Priority:
P0 if Kashi wants any employee-trust story to survive

----------------------------------------------------------------------
4.3 TELEMETRY PARTITIONING
----------------------------------------------------------------------

Consideration:
Protected-route logs, product analytics, employer-facing analytics, and security telemetry cannot all share the same visibility plane.

Critical verification:
This point remains valid and got stronger after checking the retaliation memo.
Frontend concealment is not enough if analytics exhaust leaks protected-state activity.

If taken into the plan, minimum acceptance criteria:
- protected-route events are segregated from employer-facing BI / product analytics,
- security / reliability logs have separate permissions,
- retention and access policies differ by telemetry class,
- employer-side product users cannot query protected-state activity.

----------------------------------------------------------------------
4.4 ANTI-INFERENCE / SMALL-TEAM PROTECTION
----------------------------------------------------------------------

Consideration:
Names removed does not mean identity protected.

Danger signals:
- very small teams,
- rare roles,
- timing correlation,
- only one junior / one dissenting person,
- narrow event windows,
- repeated dyads.

Critical verification:
Still real.
This is not over-paranoia; it is explicitly grounded in the retaliation and trust memos.

If taken into the plan, minimum acceptance criteria:
- minimum group thresholds exist for employer-facing views,
- batching / delay / redaction / suppression logic exists,
- tiny-team review routes are stress-tested,
- aggregate surfaces can suppress rather than expose.

Common self-own:
Assuming k-anonymity alone solves contextual re-identification.

----------------------------------------------------------------------
4.5 EVIDENCE VAULT / USER-CONTROLLED ENCRYPTION
----------------------------------------------------------------------

Consideration:
The evidence vault is strategically strong, but only if the key lifecycle is real.

Questions to settle:
- recovery phrase or not?
- multi-device support?
- lost-key story?
- re-wrapping / rotation?
- offboarding?
- any support-access backdoor?
- escrow or no escrow?

Critical verification:
Still valid, but should be treated as conditional on whether this feature is in actual scope soon.
It is not required to prove the core analysis thesis, but if included, it needs adult design.

If taken into the plan, minimum acceptance criteria:
- written threat model,
- key lifecycle documented,
- no misleading “end-to-end” phrasing unless deserved,
- minimal share-preview / bounded-disclosure behavior exists,
- metadata protections align with anti-retaliation design.

----------------------------------------------------------------------
4.6 CONTESTABILITY / CHALLENGE WORKFLOWS
----------------------------------------------------------------------

Consideration:
If users cannot dispute transcript quality, speaker attribution, interpretation, or context, meaningful human review becomes fictional.

Critical verification:
Still strong.
This is part of procedural defensibility, not UX polish.

If taken into the plan, minimum acceptance criteria:
- challenge path exists in-product or in an explicitly defined controlled workflow,
- target types are defined (transcript / attribution / event / pattern / access),
- dispositions are logged,
- contested objects can be suppressed, annotated, or deferred.

======================================================================
5. ENTERPRISE / CONTROL SYSTEM — CONSIDERATION POINTS
======================================================================

These become more important as Kashi moves from demo to pilot to real buyer conversations.

----------------------------------------------------------------------
5.1 DATA MODEL / RETENTION / LEGAL-HOLD MODEL
----------------------------------------------------------------------

Consideration:
Different data classes should have different retention and deletion semantics.

Likely classes:
- raw meeting artifacts,
- normalized features,
- detector outputs,
- review-worthy events,
- encrypted evidence objects,
- audit logs,
- legal-hold material.

Critical verification:
Still valid.
The internal memos already point toward tiered retention; it just needs to become explicit.

If taken into the plan, minimum acceptance criteria:
- every major table/object belongs to a data class,
- every class has default retention behavior,
- legal hold is an explicit state / process,
- delete/export semantics are documented.

----------------------------------------------------------------------
5.2 TENANT ISOLATION / CUSTOMER BOUNDARY
----------------------------------------------------------------------

Consideration:
RLS alone is a mechanism, not proof.

Needed assurance artifacts if this becomes part of the plan:
- tenant-scoped table inventory,
- policy inventory,
- privileged-role inventory,
- negative tests,
- support-access policy,
- migration review procedure.

Critical verification:
Still valid.
This is primarily serious-pilot / enterprise-hardening, not concept-core science.

If taken into the plan, minimum acceptance criteria:
- tenant isolation tested, not assumed,
- support access reason-coded,
- privileged paths documented,
- cross-tenant leakage tests exist.

----------------------------------------------------------------------
5.3 RESIDENCY / DATA-BOUNDARY POSTURE
----------------------------------------------------------------------

Consideration:
If Kashi wants region-specific data stories (e.g. Japan-residency), it needs architectural discipline, not broad vibes.

Critical verification:
Still valid, but the phrasing should stay cautious.
Do not claim “all processing stays in X country” unless every path and subprocessor supports that statement.

If taken into the plan, minimum acceptance criteria:
- region selection is explicit,
- sensitive content path is documented,
- subprocessor geography map exists,
- public claims match actual architecture.

----------------------------------------------------------------------
5.4 MODEL / DATA BOUNDARY DOCUMENTATION
----------------------------------------------------------------------

Consideration:
If any non-trivial AI / semantic processing exists, the product needs a precise statement of what touches what.

Critical verification:
Still valid.
This becomes mandatory if Kashi chooses honest hybrid rather than structural-only.

If taken into the plan, minimum acceptance criteria:
- live detection path documented,
- optional model-assisted features documented separately,
- transcript-to-model routing rules explicit,
- retention and training-use implications documented where relevant.

----------------------------------------------------------------------
5.5 INCIDENT RESPONSE / RELIABILITY / AUDIT
----------------------------------------------------------------------

Consideration:
For companies, “what happens when this breaks?” matters almost as much as “what does it do?”

Critical verification:
Still valid.
This is more pilot / enterprise-hardening than first-prototype necessity, but you do not want it discovered too late.

If taken into the plan, minimum acceptance criteria:
- incident severity model exists,
- responsible roles are named,
- audit logs exist for sensitive access,
- ingestion / parser / suppression failures are observable,
- rollback path exists for detector regressions.

======================================================================
6. ROLLOUT / HUMAN-OPS SYSTEM — CONSIDERATION POINTS
======================================================================

This ring was not fluff in the earlier map; it remains real after verification.

----------------------------------------------------------------------
6.1 ROLLOUT SHOULD BE TREATED AS A GOVERNANCE PROGRAM, NOT NORMAL SAAS ENABLEMENT
----------------------------------------------------------------------

Consideration:
A Kashi pilot is not just “turn it on and gather usage.”

Critical verification:
Still strongly valid.
The rollout and labor memos support a governance-program framing.

Refined implication:
The product should support staged rollout and shadow-mode possibilities rather than assuming immediate broad visibility.

If taken into the plan, minimum acceptance criteria:
- scoped meeting classes can be configured,
- approved notice pack exists,
- access roles are configured explicitly,
- challenge / correction flow exists,
- pause / decommission trigger exists,
- rollout can happen in stages (e.g. shadow -> self-view -> mirror -> aggregate surfaces).

----------------------------------------------------------------------
6.2 WORKER / REPRESENTATIVE CONSULTATION IS NOT OPTIONAL POLITICALLY
----------------------------------------------------------------------

Consideration:
Worker involvement is part of deployment viability, not just ethics optics.

Critical verification:
Still valid.
Official and research sources support this strongly.

Refined implication:
Even if exact legal classification varies, Kashi is much safer if the rollout assumes consultation and representative involvement where relevant.

If taken into the plan, minimum acceptance criteria:
- worker-facing notice is not an afterthought,
- exclusions from scope are discussable,
- challenge and access/audit design are explainable to worker-side stakeholders,
- a “just publish a notice and go live” rollout is avoided.

----------------------------------------------------------------------
6.3 HUMAN OVERSIGHT / REVIEWER TOOLING
----------------------------------------------------------------------

Consideration:
Meaningful human review requires real reviewer tooling and workflow ownership.

Needed capabilities:
- transcript / event inspection,
- meeting-type override,
- quality-bundle inspection,
- challenge-case triage,
- safe support access,
- reason-coded exceptional review,
- resolution logging.

Critical verification:
Still valid.
Without this, “human review” becomes decorative.

If taken into the plan, minimum acceptance criteria:
- designated reviewer role exists,
- reviewer actions are logged,
- reviewer can reject / annotate / suppress outputs,
- support and reviewer privileges are not conflated.

----------------------------------------------------------------------
6.4 DOCUMENTATION AS PRODUCT SURFACE
----------------------------------------------------------------------

Consideration:
For this category, methodology notes, worker notices, reviewer guidance, and boundary memos are part of the product, not side docs.

Critical verification:
Still valid.
Especially important because Kashi’s credibility depends on being explainable and bounded.

If taken into the plan, minimum acceptance criteria:
- worker notice pack,
- admin implementation guide,
- detector methodology note,
- challenge / appeal explainer,
- data-boundary / governance note,
- meeting-type support matrix.

======================================================================
7. SECOND-ORDER BUT REAL DOMAINS THAT WERE WORTH KEEPING
======================================================================

These survived critical review, but they should be treated carefully: some are not first-sprint essentials, yet they are still real.

----------------------------------------------------------------------
7.1 IDENTITY / ORG GRAPH / ENTITLEMENT SYNC
----------------------------------------------------------------------

Why it remains real:
Kashi is role-, dyad-, team-, and manager-sensitive.
Without reliable org graph / role entitlement, manager mirror, meeting-type normalization, and aggregate surfaces get distorted.

If taken into the plan, minimum acceptance criteria:
- stable user identity mapping,
- manager/team relationship source documented,
- external participant state tracked,
- low-confidence identity mappings can suppress certain interpretations.

----------------------------------------------------------------------
7.2 CHANGE HISTORY / RE-COMPUTATION POLICY
----------------------------------------------------------------------

Why it remains real:
Detector logic, preprocessing, and policy registries will change.
So you need a rule for whether past outputs are immutable snapshots, recomputed, or dual-versioned.

If taken into the plan, minimum acceptance criteria:
- output versioning exists,
- recomputation policy exists,
- audit/reviewer surfaces can see logic version,
- score changes caused by version changes are not silently treated as real-world behavioral change.

----------------------------------------------------------------------
7.3 OBSERVABILITY / OPS TELEMETRY
----------------------------------------------------------------------

Why it remains real:
Without operational observability, missing meetings, parser failures, or detector suppression anomalies become invisible.

If taken into the plan, minimum acceptance criteria:
- ingestion failure monitoring,
- parser error monitoring,
- suppression-rate monitoring,
- detector health dashboards,
- audit-log integrity checks.

----------------------------------------------------------------------
7.4 EMPLOYEE / TEAM LIFECYCLE STATES
----------------------------------------------------------------------

Why it remains real:
New joiners, reorgs, role changes, transfers, rare attendees, and low-history participants all break naive baseline logic.

If taken into the plan, minimum acceptance criteria:
- “insufficient history” state exists,
- baseline invalidation / migration policy exists,
- new-manager cold start does not pretend to be stable pattern evidence.

----------------------------------------------------------------------
7.5 CUSTOMER CONFIGURATION BOUNDARIES
----------------------------------------------------------------------

Why it remains real:
Too much configurability can destroy the product’s trust mechanism.

Refined guidance:
Safe-ish config:
- scope selection,
- retention within guardrails,
- locale / meeting-type enablement,
- reviewer role assignment,
- notification cadence.

Dangerous config:
- disabling anonymity thresholds,
- exposing named subordinate telemetry,
- bypassing challenge / logging,
- using outputs for appraisal / discipline,
- arbitrary detector-threshold manipulation for punitive goals.

If taken into the plan, minimum acceptance criteria:
- some controls are hard-coded and not customer-tunable,
- anti-misuse boundaries are technical, not only contractual.

----------------------------------------------------------------------
7.6 KILL SWITCHES / PAUSE / DECOMMISSION LOGIC
----------------------------------------------------------------------

Why it remains real:
A governance product needs explicit “stop” states.
The rollout memo supports pause / decommission logic where trust or control failures exceed tolerance.

If taken into the plan, minimum acceptance criteria:
- pilot pause trigger exists,
- detector rollback path exists,
- misuse / trust-failure threshold can trigger restriction or shutdown.

======================================================================
8. WHAT SHOULD LIKELY BE TREATED AS CORE VS CONDITIONAL VS LATER
======================================================================

This is the cleanest refinement after verification.

----------------------------------------------------------------------
8.1 LIKELY CORE IF KASHI WANTS TO BE INTERNALLY COHERENT
----------------------------------------------------------------------

- target construct decision
- structural-only vs honest hybrid decision
- ingestion + normalization
- input-quality gating
- measurement layer
- abstention
- baseline logic (at least partial)
- constrained visibility model
- anti-retaliation protected states
- telemetry partitioning
- meeting-type handling (even if initially coarse)
- challenge / correction path at least in basic form

----------------------------------------------------------------------
8.2 CONDITIONAL — REQUIRED IF KASHI WANTS STRONGER CLAIMS OR SERIOUS PILOTS
----------------------------------------------------------------------

- full detector taxonomy documentation
- fuller baseline stack
- locale / multilingual packs
- reviewer tooling maturity
- rollout gate model
- worker / representative consultation packet
- retention / hold / delete matrix
- model/data-boundary memo
- tenant-isolation evidence
- anti-inference hardening for small teams

----------------------------------------------------------------------
8.3 LIKELY LATER-STAGE / ENTERPRISE-HARDENING
----------------------------------------------------------------------

- mature evidence vault with full key lifecycle
- formal security assurance pack
- deep residency story
- advanced observability / ops dashboards
- broad locale expansion
- richer customer admin controls
- extensive support tooling
- more formal decommission / rollback governance

======================================================================
9. A CLEANER DECISION-REGISTER TEMPLATE FOR THE TEAM
======================================================================

Use something like this for each item while the plan is being built:

Decision / consideration:
Why it matters:
What happens if we ignore it:
Possible stances:
Recommended current stance:
Required before MVP? (Y/N)
Required before pilot? (Y/N)
Required before enterprise sale? (Y/N)
If adopted, minimum acceptance criteria:
Who owns the decision:
Open questions:
Source / rationale:

======================================================================
10. FINAL REFINED JUDGMENT
======================================================================

The earlier architecture map was directionally right, but after verification the cleanest refined statement is:

Kashi should not be planned as a single analytics feature set.
It should be planned as a layered system whose coherence depends on three linked choices:

1) epistemic discipline
   - what Kashi claims to estimate,
   - what it refuses to claim,
   - how uncertainty and abstention are handled;

2) constrained visibility
   - who can see what,
   - which states remain private,
   - how inference and retaliation risks are reduced;

3) staged deployability
   - what is required for a concept demo,
   - what is required for a governance-safe pilot,
   - what is required for serious buyer scrutiny.

The main practical refinement is this:
do not force every consideration point into the first fixed plan.
Instead, classify each point by:
- whether it is needed for conceptual honesty,
- whether it is needed for pilot legitimacy,
- whether it is needed for enterprise hardening.

That is the safest way to avoid two bad outcomes at once:
- underbuilding the product into incoherence,
- or overfreezing the plan around one perspective too early.

======================================================================
11. SOURCE NOTE
======================================================================

This refined register was pressure-tested against:
- internal Kashi memos on measurement science, retaliation risk, trust, labor relations, and rollout,
- the Kashi progress deck,
- and a small set of current official-source checks on:
  - Google Meet transcripts support,
  - Microsoft Teams recording/transcription documentation,
  - Zoom AI Companion language support,
  - the European Commission’s AI Act materials,
  - the NIST AI RMF Playbook.

Important source-handling note:
Current official-source checks support cautious statements such as:
- Google Meet transcripts remain an official supported feature with language limits and organizer-drive storage behavior.
- Teams recording/transcription is a live official feature area, but some exact documentation paths are access-fragmented, so exact claims should be phrased carefully.
- Zoom language support is broad but feature-specific.
- The Commission’s current AI Act materials still state that emotion recognition in workplaces is prohibited and that deployers of high-risk AI systems at the workplace must inform affected employees and workers’ representatives.
- The NIST AI RMF Playbook remains voluntary and explicitly says it is not a checklist.

This file therefore prefers cautious, architecture-relevant statements over brittle one-line compliance claims.