@mindrian_os/cli 2.0.0-beta.3 → 2.0.0-beta.31

package/references/meeting/knowledge-typing.md

@@ -0,0 +1,242 @@
+<!--
+  Phase 150.8-03 (DIKW-05) -- the knowledge-typing reference: the 6-enum
+  knowledge taxonomy + conditions/counter_conditions + temporal validity that
+  the Claimify typing pass (Step 3 pass 4 of commands/file-meeting.md) classifies
+  each ATOMIC claim against before calling navigation.writeClaimNode.
+
+  Reuse-before-build (Canon Part 7): this EXTENDS /mos:file-meeting and the
+  references/meeting/segment-classification.md reference. Repointing the existing
+  segment-classification.md is INSUFFICIENT: that reference carries the SEGMENT
+  taxonomy (decision / action-item / insight / advice / question / noise -- the
+  routing-and-priority layer). The 6 knowledge_type semantics here
+  (fact / causal / heuristic / anomaly_cue / mental_model / assumption) are
+  NET-NEW: no existing reference carries the Ackoff DIKW knowledge rungs, the
+  conditions/counter_conditions contrastive extraction, or the valid_from/
+  valid_until temporal validity that writeClaimNode persists. The segment type
+  answers "where does this file and how urgent"; the knowledge_type answers
+  "what RUNG of knowledge is this and under what conditions does it hold". They
+  compose: a segment is SELECTED, DISAMBIGUATED, DECOMPOSED, then each atomic
+  claim is TYPED here.
+
+  This file is the typing-pass authority. It is LLM prose (judgment), NOT a CJS
+  extractor. NO em-dashes anywhere (CLAUDE.md HARD RULE).
+-->
+
+# Knowledge Typing -- the DIKW 6-Type Taxonomy
+
+After a segment is selected, disambiguated, and decomposed into atomic claims
+(Step 3 passes 1 to 3 of `/mos:file-meeting`), each atomic claim is classified
+against the closed 6-member `knowledge_type` enum below. The enum is frozen in
+`lib/core/navigation/typed-claim.cjs` (`KNOWLEDGE_TYPES`); a claim whose type is
+not one of these six is rejected `invalid_knowledge_type` by `writeClaimNode`.
+
+The six types are the Ackoff DIKW rungs made concrete for meeting micro-knowledge:
+
+| knowledge_type | DIKW rung | One-line test |
+|----------------|-----------|---------------|
+| `fact` | Data / Information | A stated state of the world that is true or false |
+| `anomaly_cue` | Data / Information | A noticed surprise, an outlier, a "that is weird" signal |
+| `causal` | Knowledge | An X-causes-Y mechanism claim |
+| `heuristic` | Knowledge | A rule of thumb, an if-then operating rule |
+| `mental_model` | Knowledge | A belief about how a system or market works |
+| `assumption` | Knowledge (unvalidated) | A claim taken as true without evidence yet |
+
+The typing pass picks EXACTLY ONE primary `knowledge_type` per atomic claim. When
+a claim reads as two types, resolve with the Multi-Type rules at the end.
+
+---
+
+## 1. fact
+
+**Definition:** A stated state of the world. Verifiable in principle, true or
+false, not a mechanism and not a rule. The raw Data/Information rung.
+
+**Signal phrases:**
+- "Revenue was $1.2M last quarter."
+- "We have 14 paying customers."
+- "The trial enrolled 30 patients."
+- "Our churn is 4 percent monthly."
+
+**Confidence indicators:**
+- HIGH: specific number or named entity with a clear referent.
+- MEDIUM: a stated fact with a soft hedge ("about 14 customers").
+- LOW: a fact with no referent or unresolved pronoun (route to disambiguation).
+
+**conditions / counter_conditions:** Usually empty for a bare fact. If the
+speaker scopes it ("in the enterprise segment"), capture that scope as
+`conditions`.
+
+---
+
+## 2. anomaly_cue
+
+**Definition:** A noticed surprise, outlier, or tension. The speaker flags
+something that does not fit the expected pattern. This is the Information rung
+where attention spikes. anomaly_cue is the embryo of a future causal claim.
+
+**Signal phrases:**
+- "That is strange, churn dropped right after we raised the price."
+- "I would not have expected enterprise to close faster than SMB."
+- "Something is off about that cohort."
+- "Why would usage go up when we removed the feature?"
+
+**Confidence indicators:**
+- HIGH: an explicit surprise marker plus a concrete observation.
+- MEDIUM: an implied surprise without a stated expectation.
+- LOW: ordinary curiosity with no outlier (likely a `question`, not anomaly_cue).
+
+**conditions / counter_conditions:** Capture the context where the anomaly was
+seen as `conditions` ("after the price raise"). The counter is the expected
+baseline ("usually a price raise lifts churn").
+
+---
+
+## 3. causal
+
+**Definition:** An X-causes-Y mechanism claim. The Knowledge rung. A causal claim
+is the natural source of a `ROOT_CAUSES` edge (source = cause, target = effect).
+
+**Signal phrases:**
+- "Raising the price filtered out the low-intent buyers, so churn dropped."
+- "The 18-month sales cycle is driven by procurement, not by our pitch."
+- "We lost the deal because the security review stalled."
+
+**Confidence indicators:**
+- HIGH: explicit cause-and-effect with a named mechanism.
+- MEDIUM: correlation stated as cause ("when we do X, Y happens").
+- LOW: a vague link ("that might be why").
+
+**conditions / counter_conditions:** The contrastive probe matters most here.
+`conditions` = when the mechanism holds ("for self-serve buyers"). 
+`counter_conditions` = when it breaks ("not for enterprise, where procurement
+dominates").
+
+---
+
+## 4. heuristic
+
+**Definition:** A rule of thumb, an if-then operating rule the team uses to
+decide. The Knowledge rung expressed as a portable rule.
+
+**Signal phrases:**
+- "If a lead does not reply in 48 hours, we drop it."
+- "We never discount above 15 percent."
+- "Always send the security packet before the second call."
+- "As a rule, enterprise needs three touchpoints."
+
+**Confidence indicators:**
+- HIGH: a clear if-then or always/never rule.
+- MEDIUM: a general practice without a sharp boundary.
+- LOW: a one-off action stated as if it were a rule.
+
+**conditions / counter_conditions:** `conditions` = the trigger ("if no reply in
+48h"). `counter_conditions` = the exception ("unless it is a referral").
+
+---
+
+## 5. mental_model
+
+**Definition:** A belief about how a system, market, or stakeholder behaves. The
+Knowledge rung as a worldview. Mental models are the abstractions that concrete
+claims `INSTANTIATES`.
+
+**Signal phrases:**
+- "Enterprise buyers care about risk reduction, not features."
+- "This market is winner-take-most."
+- "Investors in this space want a regulatory moat before traction."
+
+**Confidence indicators:**
+- HIGH: a clear stated model of behavior with a named actor.
+- MEDIUM: a generalization from limited cases.
+- LOW: an aside that could be opinion (consider `assumption`).
+
+**conditions / counter_conditions:** `conditions` = the regime the model applies
+to ("in regulated verticals"). `counter_conditions` = where the model fails
+("consumer markets reward features over risk").
+
+---
+
+## 6. assumption
+
+**Definition:** A claim taken as true without evidence yet. The unvalidated
+Knowledge rung. This formalizes the assumption-extraction embryo already in
+`segment-classification.md` ("Every insight implies an assumption. Extract it").
+Every assumption carries an implicit validity status and is a first-class
+tracked entity (Key Decision 12).
+
+**Signal phrases:**
+- "We are assuming the TAM is $190M."
+- "I think customers will pay $50 a seat, but we have not tested it."
+- "Presumably procurement signs off in two weeks."
+- Any insight restated as a claim with `status: unvalidated`.
+
+**Confidence indicators:**
+- HIGH: an explicit "we assume / I think / presumably" marker.
+- MEDIUM: a stated belief offered as fact but unsupported (Evidence tier None).
+- LOW: a hope phrased as a plan.
+
+**conditions / counter_conditions:** `conditions` = what would make it true
+("if our pricing survey holds"). `counter_conditions` = what would invalidate it
+("if competitors anchor lower").
+
+---
+
+## The conditions / counter_conditions extraction (CTA contrastive probing)
+
+For EVERY atomic claim, before writing it, run the two-sided probe. This is the
+contrastive-thinking-aloud (CTA) move that turns a flat claim into a conditioned
+one the graph can refine later:
+
+1. **When does this hold?** -> `conditions`
+2. **When does this break?** -> `counter_conditions`
+
+If the transcript answers neither, leave both empty strings (the default in
+`writeClaimNode`). Do NOT invent conditions the speaker did not state. The probe
+is extraction, not fabrication.
+
+A claim that carries non-empty `conditions` is Wisdom-ready: it knows its own
+boundary. `/mos:build-knowledge` later groups conditioned claims onto the Wisdom
+rung.
+
+## Temporal validity (valid_from / valid_until -- TV-01)
+
+When a claim is time-bound, extract its temporal envelope:
+
+- `valid_from` -- the date the claim starts being true ("starting next quarter",
+  "as of the March release"). ISO `YYYY-MM-DD` when stated; empty otherwise.
+- `valid_until` -- the date it stops being true or expires ("until the contract
+  renews", "good through end of year"). Empty when open-ended.
+
+Both ride the claim's properties JSON; neither is a column. Leave empty strings
+when the transcript states no time bound. These also ride the edge `properties`
+when a REFINES / ROOT_CAUSES / INSTANTIATES edge is later minted between claims
+(zero writeEdge signature change).
+
+## Disambiguation marker (ambiguous claims)
+
+If pass 2 (disambiguation) could not resolve a referent (a pronoun with no
+speaker-attributable antecedent across the prior 2 to 3 turns), the claim is
+STILL minted, with `disambiguation: 'ambiguous'`. It is queued for human review,
+never silently dropped. It lands `review_status: proposed` like every truth
+claim, and the SessionStart ambiguous-queue hook resurfaces it with a mandatory
+Dismiss. Pick the single MOST-LIKELY `knowledge_type` even for an ambiguous
+claim, so the queued node is still typed.
+
+## Multi-Type resolution
+
+When an atomic claim reads as two knowledge_types:
+
+1. **causal beats fact** when a mechanism is stated ("churn dropped BECAUSE we
+   raised the price" is `causal`, not two `fact`s).
+2. **assumption beats fact** when the claim is explicitly unvalidated ("we assume
+   revenue will double" is `assumption`).
+3. **anomaly_cue beats fact** when the framing is surprise ("strangely, revenue
+   was flat" is `anomaly_cue`).
+4. **heuristic beats mental_model** when the claim is an actionable rule rather
+   than a belief about behavior.
+5. If still tied, pick the HIGHER rung (Knowledge over Data): causal / heuristic
+   / mental_model / assumption over fact / anomaly_cue.
+
+Decomposition (pass 3) should have already split a compound segment so that each
+atomic claim has ONE dominant type. If you still see two, the segment was not
+fully decomposed; split it again.

package/references/meeting/live-join-interface.md

@@ -0,0 +1,244 @@
+# Live Join Interface -- External Transcript Source Design Spec
+
+*Design specification for future `--join` and `--latest` flags. NOT implemented in Phase 6.*
+
+---
+
+## Status
+
+| Feature | Phase | Status |
+|---------|-------|--------|
+| `file-meeting` (paste/upload) | Phase 6 | Active development |
+| `file-meeting --latest` | Phase 8 | Design only |
+| `file-meeting --join <url>` | Phase 9+ | Design only |
+
+This document defines the interface contract so that future phases can implement external transcript sources without changing the core filing pipeline.
+
+---
+
+## Interface Contract
+
+All external transcript sources MUST produce output in one of the supported formats defined in `references/meeting/transcript-patterns.md`. The filing pipeline does not change -- only the input source changes.
+
+```
+External Source -> Transcript (supported format) -> file-meeting pipeline -> Room
+```
+
+### Input Normalization
+
+Any external source adapter must output:
+1. A text file in Zoom, Teams, Otter, Meet, or Raw format, OR
+2. A JSON file in Velma format (with `speaker_id`, `text`, `start_time`, `end_time`, `emotions[]`)
+
+The `file-meeting` command does not know or care where the transcript came from. It only knows formats.
+
+---
+
+## `--latest` Flag (Phase 8)
+
+**Purpose:** Pull the most recent meeting transcript from a connected service.
+
+### Usage
+
+```bash
+/mos:file-meeting --latest
+/mos:file-meeting --latest --source read-ai
+/mos:file-meeting --latest --source velma
+```
+
+### Behavior
+
+1. Query the configured transcript source for the most recent meeting
+2. Download the transcript
+3. Convert to a supported format if needed
+4. Pass to the standard `file-meeting` pipeline
+5. Include `source: {service-name}` in artifact frontmatter
+
+### Source Priority (when no `--source` specified)
+
+1. Velma (if configured) -- highest quality (emotions, diarization)
+2. Read AI MCP (if configured) -- broadest meeting platform coverage
+3. Recall.ai (if configured) -- fallback
+
+### Configuration
+
+```json
+// .mcp.json or room config
+{
+  "transcript_sources": {
+    "velma": {
+      "api_url": "ENV:VELMA_API_URL",
+      "api_key": "ENV:VELMA_API_KEY"
+    },
+    "read_ai": {
+      "mcp_server": "read-ai-mcp"
+    },
+    "recall_ai": {
+      "api_key": "ENV:RECALL_API_KEY"
+    }
+  }
+}
+```
+
+---
+
+## `--join` Flag (Phase 9+)
+
+**Purpose:** Join a live meeting and transcribe in real-time, filing segments as they occur.
+
+### Usage
+
+```bash
+/mos:file-meeting --join https://zoom.us/j/123456789
+/mos:file-meeting --join https://teams.microsoft.com/l/meetup-join/...
+```
+
+### Behavior
+
+1. Connect to the meeting via an attend-mcp compatible service
+2. Stream transcript segments in real-time
+3. Classify and file segments as they arrive (with user confirmation batched)
+4. Produce the meeting summary when the meeting ends or user disconnects
+
+### Live Filing Modes
+
+| Mode | Description | User Interaction |
+|------|-------------|------------------|
+| silent | Transcribe and classify, file after meeting ends | Post-meeting confirm-then-file |
+| notify | Transcribe and classify, surface high-priority items live | User sees notifications during meeting |
+| interactive | Full confirm-then-file during the meeting | User approves each filing in real-time |
+
+Default: `silent` -- do not interrupt the meeting.
+
+---
+
+## External Service Comparison
+
+### attend-mcp (github.com/xpos/attend-mcp)
+
+| Attribute | Value |
+|-----------|-------|
+| Type | MCP server |
+| Cost | Open source (free) |
+| Self-hostable | Yes |
+| Platforms | Zoom, Teams, Google Meet |
+| Diarization | Basic (speaker labels from platform) |
+| Emotions | No |
+| Real-time | Yes (streaming) |
+| Integration | MCP tool calls |
+
+**Best for:** Self-hosted deployments, privacy-conscious users, developers.
+
+### Recall.ai
+
+| Attribute | Value |
+|-----------|-------|
+| Type | API service |
+| Cost | ~$0.50/hour |
+| Self-hostable | No |
+| Platforms | Zoom, Teams, Google Meet, Webex, GoTo |
+| Diarization | Yes (high quality) |
+| Emotions | No |
+| Real-time | Yes (webhooks) |
+| Integration | REST API + webhooks |
+
+**Best for:** Production deployments, broadest platform support, reliable diarization.
+
+### Vexa
+
+| Attribute | Value |
+|-----------|-------|
+| Type | Open source platform |
+| Cost | Free (self-hosted) |
+| Self-hostable | Yes (Apache-2.0) |
+| Platforms | Zoom, Teams, Google Meet |
+| Diarization | Yes |
+| Emotions | Basic sentiment |
+| Real-time | Yes |
+| Integration | REST API |
+
+**Best for:** Self-hosted deployments, budget-conscious teams, open-source preference.
+
+### Modulate Velma (already integrated -- Phase 6, Plan 02)
+
+| Attribute | Value |
+|-----------|-------|
+| Type | API service |
+| Cost | ~$0.03/hour |
+| Self-hostable | No |
+| Platforms | Audio files (not live join) |
+| Diarization | Yes (native, high quality) |
+| Emotions | Yes (20+ categories) |
+| Real-time | No (file upload) |
+| Integration | REST API (scripts/transcribe-velma) |
+
+**Best for:** Audio file transcription, emotion-aware filing, lowest cost per hour.
+
+---
+
+## Adapter Interface
+
+Future adapters must implement this contract:
+
+```bash
+# Adapter script interface
+# Input: meeting URL or "latest" command
+# Output: transcript file in supported format, written to stdout or specified path
+# Exit: 0 on success, 1 on failure
+
+scripts/adapters/{source-name} [--latest | --join <url>] [--output <path>]
+```
+
+### Required Adapter Outputs
+
+1. Transcript file (in a supported format)
+2. Meeting metadata (written to stderr as JSON):
+   ```json
+   {
+     "meeting_name": "...",
+     "meeting_date": "YYYY-MM-DD",
+     "duration_minutes": 60,
+     "platform": "zoom",
+     "speakers_detected": 4
+   }
+   ```
+
+### Error Handling
+
+| Error | Adapter Behavior |
+|-------|-----------------|
+| Auth required | Exit 1 with message: "Authentication required. Run: {auth command}" |
+| Meeting not found | Exit 1 with message: "No meeting found at {url}" |
+| Service unavailable | Exit 1 with message: "{service} is unreachable" |
+| Timeout | Exit 1 after 30 seconds with message: "Connection timed out" |
+
+---
+
+## Phase Dependencies
+
+```
+Phase 6 (current):
+  - file-meeting accepts paste/upload
+  - Velma transcribes audio files
+  - No external live sources
+
+Phase 8 (--latest):
+  - Read AI MCP integration
+  - Pull most recent transcript
+  - Same pipeline, new input source
+
+Phase 9+ (--join):
+  - attend-mcp or Recall.ai integration
+  - Live meeting attendance
+  - Real-time transcript streaming
+  - Post-meeting or live filing modes
+```
+
+---
+
+## Cross-Reference
+
+- Supported transcript formats: `references/meeting/transcript-patterns.md`
+- Velma integration: `scripts/transcribe-velma` (Phase 6, Plan 02)
+- Filing pipeline: `references/meeting/artifact-template.md`
+- Read AI requirements: RDAI-01, RDAI-02, RDAI-03 (Phase 8)

package/references/meeting/section-mapping.md

@@ -0,0 +1,192 @@
+# Section Mapping Matrix -- Speaker Role x Segment Type x Room Section
+
+*Used by `file-meeting` to route classified segments to the correct room section.*
+
+---
+
+## The 12 Speaker Roles
+
+| Role | Description | Typical Context |
+|------|-------------|-----------------|
+| mentor | Teaching advisor, framework guide | Academic, accelerator |
+| researcher | Subject matter researcher, analyst | Research team, consultants |
+| team-member | Core team, employees | Internal meetings |
+| investor | VC, angel, LP, fund manager | Pitch, board, due diligence |
+| advisor | Strategic or technical advisor | Advisory board |
+| customer | Current or potential customer | Discovery, feedback |
+| founder | Company founder, CEO | All meetings |
+| partner | Business partner, channel partner | Partnership discussions |
+| domain-expert | Industry expert, specialist | Expert interviews |
+| government | Regulator, government official | Compliance, grants |
+| competitor | Known competitor representative | Conferences, panels |
+| unknown | Unidentified speaker | Raw paste, unlabeled |
+
+---
+
+## The 8 Room Sections
+
+| Section | Primary Content |
+|---------|----------------|
+| problem-definition | Problem framing, assumptions, scope, unknowns |
+| market-analysis | Market size, trends, timing, customer needs |
+| solution-design | Architecture, features, technical approach |
+| business-model | Revenue, pricing, unit economics, channels |
+| competitive-analysis | Competitors, positioning, differentiation |
+| team-execution | Team, hiring, capabilities, leadership |
+| legal-ip | IP, patents, regulation, compliance |
+| financial-model | Funding, valuation, projections, burn rate |
+
+---
+
+## Routing Matrix
+
+The matrix below maps `(speaker_role, segment_type)` to the primary room section and priority modifier.
+
+**Reading the matrix:** Each cell contains `section (+priority_modifier)`. Empty cells mean "Larry decides based on content" -- the combination is too context-dependent for a fixed rule.
+
+### decision
+
+| Speaker Role | Primary Section | Priority Modifier | Notes |
+|-------------|----------------|-------------------|-------|
+| founder | *content-dependent* | +1 | Founders decide across all sections |
+| investor | financial-model | +2 | Unless explicitly about another section |
+| mentor | problem-definition | +1 | Mentors guide problem framing decisions |
+| advisor | *content-dependent* | +1 | Advisors span multiple domains |
+| team-member | team-execution | 0 | Unless clearly about another section |
+| customer | solution-design | +1 | Customer decisions inform product |
+| researcher | market-analysis | 0 | Research findings drive decisions |
+| partner | business-model | +1 | Partnership decisions affect model |
+| domain-expert | *content-dependent* | +1 | Expert domain determines section |
+| government | legal-ip | +2 | Regulatory decisions are highest priority |
+| competitor | competitive-analysis | 0 | Competitor decisions are intel |
+| unknown | *content-dependent* | -1 | Lower confidence without role context |
+
+### action-item
+
+| Speaker Role | Primary Section | Priority Modifier | Notes |
+|-------------|----------------|-------------------|-------|
+| founder | *content-dependent* | +1 | Founder-assigned actions are high priority |
+| investor | financial-model | +2 | Investor requests are critical |
+| mentor | *content-dependent* | +1 | Mentor-assigned homework |
+| advisor | *content-dependent* | +1 | Advisor follow-ups |
+| team-member | team-execution | 0 | Standard task tracking |
+| customer | solution-design | +1 | Customer-requested features |
+| researcher | market-analysis | 0 | Research tasks |
+| partner | business-model | 0 | Partnership deliverables |
+| domain-expert | *content-dependent* | 0 | Expert recommendations to pursue |
+| government | legal-ip | +1 | Compliance requirements |
+| competitor | competitive-analysis | -1 | Rare -- flagged for review |
+| unknown | *content-dependent* | -1 | Low confidence assignment |
+
+### insight
+
+| Speaker Role | Primary Section | Priority Modifier | Notes |
+|-------------|----------------|-------------------|-------|
+| founder | *content-dependent* | 0 | Founder insights span all sections |
+| investor | financial-model | +1 | Investor insights signal deal criteria |
+| mentor | problem-definition | +1 | Mentor insights reframe the problem |
+| advisor | *content-dependent* | +1 | Advisor insights from experience |
+| team-member | *content-dependent* | 0 | Context-dependent |
+| customer | market-analysis | +2 | Customer insights are primary market data |
+| researcher | market-analysis | +1 | Research findings |
+| partner | business-model | +1 | Partnership ecosystem data |
+| domain-expert | *content-dependent* | +1 | Expert knowledge is high value |
+| government | legal-ip | +1 | Regulatory landscape intelligence |
+| competitor | competitive-analysis | +2 | Competitor admissions are gold |
+| unknown | *content-dependent* | -1 | Needs attribution for proper routing |
+
+### advice
+
+| Speaker Role | Primary Section | Priority Modifier | Notes |
+|-------------|----------------|-------------------|-------|
+| founder | team-execution | 0 | Founder advice usually about execution |
+| investor | financial-model | +2 | Investor advice signals expectations |
+| mentor | problem-definition | +1 | Mentor guidance on framing |
+| advisor | *content-dependent* | +2 | Advisors' PRIMARY output is advice |
+| team-member | *content-dependent* | 0 | Peer suggestions |
+| customer | solution-design | +1 | Customer suggestions = feature requests |
+| researcher | *content-dependent* | 0 | Research recommendations |
+| partner | business-model | +1 | Partnership strategy guidance |
+| domain-expert | *content-dependent* | +2 | Expert recommendations are high value |
+| government | legal-ip | +1 | Compliance guidance |
+| competitor | competitive-analysis | -2 | Competitor "advice" is suspect -- flag |
+| unknown | *content-dependent* | -1 | Unattributed advice has less weight |
+
+### question
+
+| Speaker Role | Primary Section | Priority Modifier | Notes |
+|-------------|----------------|-------------------|-------|
+| founder | *content-dependent* | 0 | Founder questions reveal their blind spots |
+| investor | financial-model | +2 | Investor questions signal due diligence gaps |
+| mentor | problem-definition | +1 | Mentor questions are diagnostic |
+| advisor | *content-dependent* | +1 | Advisor questions reveal risks |
+| team-member | *content-dependent* | 0 | Operational questions |
+| customer | market-analysis | +2 | Customer questions reveal unmet needs |
+| researcher | *content-dependent* | 0 | Research questions |
+| partner | business-model | +1 | Partnership feasibility concerns |
+| domain-expert | *content-dependent* | +1 | Expert questions expose technical gaps |
+| government | legal-ip | +2 | Regulatory questions are compliance flags |
+| competitor | competitive-analysis | +1 | Competitor questions reveal their strategy |
+| unknown | *content-dependent* | -1 | Low priority without role context |
+
+### noise
+
+Noise segments are SKIPPED unless flagged by the Flag Potential Noise Rule (see `segment-classification.md`). No routing matrix needed. Flagged noise goes to user review.
+
+---
+
+## Content-Dependent Routing
+
+When the matrix shows `*content-dependent*`, Larry uses keyword analysis to determine the section:
+
+1. Run the segment text through `scripts/classify-insight` keyword patterns
+2. If `classify-insight` returns `SUGGEST:{section}:MEDIUM`, use that section
+3. If `UNCERTAIN`, analyze context:
+   - What section was the conversation discussing before this segment?
+   - What keywords appear in the segment? (see keyword lists below)
+   - What is the speaker's domain of expertise?
+4. If still uncertain, ask the user: "Where should I file this {type} from {speaker}?"
+
+**Section keyword hints:**
+
+| Section | Keywords |
+|---------|----------|
+| problem-definition | problem, challenge, issue, scope, definition, assumption, unknown, question, gap, need |
+| market-analysis | market, customer, trend, TAM, SAM, growth, segment, user, demand, adoption, timing |
+| solution-design | product, feature, architecture, design, technology, platform, integration, UX, build |
+| business-model | revenue, pricing, model, channel, cost, unit economics, margin, subscription, sales |
+| competitive-analysis | competitor, alternative, moat, differentiation, advantage, threat, positioning, benchmark |
+| team-execution | team, hire, role, culture, leadership, process, execution, sprint, velocity, roadmap |
+| legal-ip | legal, patent, IP, regulation, compliance, license, terms, privacy, GDPR |
+| financial-model | funding, valuation, runway, burn, projection, revenue, cap table, dilution, round |
+
+---
+
+## Priority Scoring
+
+Final filing priority = base_segment_priority + role_modifier + content_relevance
+
+| Base Priority | Score |
+|---------------|-------|
+| decision | 10 |
+| action-item | 8 |
+| insight | 6 |
+| advice | 6 |
+| question | 4 |
+| noise | 0 |
+
+**Role modifier:** From the routing matrix above (-2 to +2).
+
+**Content relevance:** +1 if the segment directly references the target section's domain. +0 otherwise.
+
+**Filing order:** Segments are filed highest-priority first. This ensures decisions and actions are captured before the user fatigues during the confirm-then-file loop.
+
+---
+
+## Cross-Reference Vocabulary
+
+The section names and classification vocabulary in this file are shared with:
+- `scripts/classify-insight` -- uses the same 8 section names and keyword patterns
+- `references/meeting/segment-classification.md` -- defines the 6 segment types referenced here
+- `references/meeting/artifact-template.md` -- `room_section` and `segment_type` fields use these exact values
+- `skills/room-passive/SKILL.md` -- provenance metadata uses the same section vocabulary