Add RSA extraction bootstrap and working notes
This commit is contained in:
305
docs/legache_smartwatch_mvp_proposal.md
Normal file
305
docs/legache_smartwatch_mvp_proposal.md
Normal file
@@ -0,0 +1,305 @@
|
||||
# Legache Smartwatch MVP Proposal
|
||||
|
||||
This document proposes a narrowly scoped MVP for exploring a collaboration
|
||||
between Legache and `whetstone_RSA`.
|
||||
|
||||
The goal is not to build general-purpose AI on a smartwatch.
|
||||
|
||||
The goal is to validate whether a **bounded local knowledge interface** can
|
||||
deliver useful enterprise value on wearable hardware with local latency and a
|
||||
tightly constrained semantic interpretation layer.
|
||||
|
||||
---
|
||||
|
||||
## 1. MVP Goal
|
||||
|
||||
Build a smartwatch-scale interface that allows a user to issue short voice or
|
||||
text requests against a locally synced Legache knowledge corpus and receive fast,
|
||||
bounded, useful results.
|
||||
|
||||
The MVP should demonstrate:
|
||||
|
||||
- local or near-local latency
|
||||
- useful interpretation of messy short requests
|
||||
- deterministic retrieval and display behavior
|
||||
- clear separation between semantic interpretation and execution
|
||||
|
||||
---
|
||||
|
||||
## 2. Product Hypothesis
|
||||
|
||||
If Legache already provides efficient local indexing, metadata, and retrieval for
|
||||
messy business information, then a small RSA-style semantic layer can turn short
|
||||
watch interactions into structured retrieval actions without needing a large
|
||||
generative model on-device.
|
||||
|
||||
In short:
|
||||
|
||||
Legache supplies the local knowledge substrate.
|
||||
RSA supplies the bounded semantic interface.
|
||||
|
||||
---
|
||||
|
||||
## 3. MVP User Experience
|
||||
|
||||
The user can:
|
||||
|
||||
- speak or type a short request
|
||||
- receive a fast answer card, result list, or target action
|
||||
- interact with local information without waiting on a cloud LLM round-trip
|
||||
|
||||
Example requests:
|
||||
|
||||
- "What's our refund deadline?"
|
||||
- "Open the PTO policy."
|
||||
- "Find the latest warehouse checklist."
|
||||
- "Who owns the Acme account?"
|
||||
- "Show yesterday's client note."
|
||||
|
||||
Example outputs:
|
||||
|
||||
- policy answer card
|
||||
- latest matching document card
|
||||
- filtered results list
|
||||
- ownership/contact card
|
||||
- open-on-phone or continue-on-device handoff
|
||||
|
||||
---
|
||||
|
||||
## 4. Narrow MVP Scope
|
||||
|
||||
Pick one domain first.
|
||||
|
||||
Recommended options:
|
||||
|
||||
- policy lookup
|
||||
- latest-note retrieval
|
||||
- checklist retrieval
|
||||
- account/contact ownership lookup
|
||||
|
||||
Recommended starting choice:
|
||||
|
||||
`policy lookup`
|
||||
|
||||
Why:
|
||||
|
||||
- bounded answer style
|
||||
- easy to evaluate
|
||||
- useful in enterprise settings
|
||||
- strong fit for short watch interactions
|
||||
|
||||
---
|
||||
|
||||
## 5. What RSA Would Own
|
||||
|
||||
For the MVP, RSA would handle:
|
||||
|
||||
- request type classification
|
||||
- entity / topic extraction
|
||||
- filter extraction when relevant
|
||||
- confidence / abstain behavior
|
||||
- generation of a bounded retrieval contract
|
||||
|
||||
Example contract:
|
||||
|
||||
```text
|
||||
mode: policy_lookup
|
||||
topic: refund_deadline
|
||||
document_family: finance_policy
|
||||
time_scope: current
|
||||
confidence: 0.94
|
||||
```
|
||||
|
||||
RSA would **not** own:
|
||||
|
||||
- full document indexing
|
||||
- full-text retrieval
|
||||
- synchronization
|
||||
- long-form answer generation
|
||||
- general reasoning over the entire corpus
|
||||
|
||||
---
|
||||
|
||||
## 6. What Legache Would Own
|
||||
|
||||
Legache would provide:
|
||||
|
||||
- synced local document corpus or local-accessible subset
|
||||
- metadata and document organization
|
||||
- retrieval/index/query interface
|
||||
- source-of-truth content
|
||||
- watch-side or companion-device data delivery path
|
||||
|
||||
Legache remains the knowledge substrate.
|
||||
|
||||
RSA sits on top as the semantic interpretation layer.
|
||||
|
||||
---
|
||||
|
||||
## 7. Proposed Architecture
|
||||
|
||||
```text
|
||||
voice/text request
|
||||
->
|
||||
speech-to-text if needed
|
||||
->
|
||||
RSA semantic gate
|
||||
->
|
||||
bounded retrieval contract
|
||||
->
|
||||
Legache retrieval/index layer
|
||||
->
|
||||
deterministic answer rendering
|
||||
->
|
||||
watch UI
|
||||
```
|
||||
|
||||
Possible deterministic UI outputs:
|
||||
|
||||
- answer card
|
||||
- snippet card
|
||||
- result list
|
||||
- "open on phone"
|
||||
- "low confidence, refine query"
|
||||
|
||||
---
|
||||
|
||||
## 8. Suggested Technical Shape
|
||||
|
||||
### Input
|
||||
|
||||
- short voice command or short text query
|
||||
|
||||
### Interpretation Layer
|
||||
|
||||
- tiny transformer or other compact bounded decision model
|
||||
- bounded output space
|
||||
- optional abstain/escalate behavior
|
||||
|
||||
### Retrieval Layer
|
||||
|
||||
- Legache local retrieval over synced documents and metadata
|
||||
|
||||
### Output Layer
|
||||
|
||||
- deterministic answer card or result list
|
||||
- no freeform generative answer requirement in MVP
|
||||
|
||||
---
|
||||
|
||||
## 9. Success Criteria
|
||||
|
||||
The MVP is successful if it shows:
|
||||
|
||||
- fast response time on target hardware or realistic companion-device setup
|
||||
- good interpretation accuracy on a small bounded domain
|
||||
- low-friction user experience for short enterprise knowledge requests
|
||||
- reliable handoff from semantic interpretation to deterministic retrieval
|
||||
|
||||
Suggested measurable targets:
|
||||
|
||||
- median latency acceptable for interactive watch use
|
||||
- high accuracy on bounded request classes
|
||||
- safe abstain behavior on out-of-scope requests
|
||||
- usable result presentation on small-screen UI
|
||||
|
||||
---
|
||||
|
||||
## 10. Evaluation Plan
|
||||
|
||||
Use a small curated query set for the chosen domain.
|
||||
|
||||
For example:
|
||||
|
||||
- 50 to 200 natural-language requests
|
||||
- multiple phrasings per intent
|
||||
- in-scope and out-of-scope examples
|
||||
- confidence and abstain evaluation
|
||||
|
||||
Evaluate:
|
||||
|
||||
- intent accuracy
|
||||
- slot extraction accuracy
|
||||
- retrieval success rate
|
||||
- end-to-end usefulness
|
||||
- latency
|
||||
|
||||
---
|
||||
|
||||
## 11. Risks
|
||||
|
||||
### Risk 1: Watch UI is too constrained
|
||||
|
||||
Mitigation:
|
||||
|
||||
- use answer cards and handoff flows
|
||||
- avoid trying to show too much text
|
||||
|
||||
### Risk 2: Voice input is noisier than expected
|
||||
|
||||
Mitigation:
|
||||
|
||||
- begin with text or constrained voice
|
||||
- keep request classes narrow
|
||||
|
||||
### Risk 3: Query interpretation is not the real bottleneck
|
||||
|
||||
Mitigation:
|
||||
|
||||
- start with a bounded domain where retrieval quality is already strong
|
||||
|
||||
### Risk 4: Open-ended expectations creep in
|
||||
|
||||
Mitigation:
|
||||
|
||||
- keep the MVP framed as bounded local knowledge lookup
|
||||
|
||||
---
|
||||
|
||||
## 12. Proposed MVP Deliverable
|
||||
|
||||
A prototype demonstrating:
|
||||
|
||||
- one bounded knowledge workflow
|
||||
- short voice/text input
|
||||
- RSA-based request interpretation
|
||||
- Legache-backed local retrieval
|
||||
- watch-scale answer rendering
|
||||
|
||||
This could be:
|
||||
|
||||
- a native watch prototype
|
||||
- a wearable mockup with companion device execution
|
||||
- or a phone-hosted prototype that simulates the target watch interaction model
|
||||
|
||||
---
|
||||
|
||||
## 13. Why This MVP Is Interesting
|
||||
|
||||
This MVP would test a meaningful product claim:
|
||||
|
||||
Can compact local retrieval plus bounded semantic interpretation create a useful
|
||||
enterprise knowledge interface on wearable hardware without depending on a large
|
||||
generative model?
|
||||
|
||||
If yes, that creates a strong story around:
|
||||
|
||||
- privacy
|
||||
- latency
|
||||
- local-first operation
|
||||
- bounded AI behavior
|
||||
- practical enterprise utility
|
||||
|
||||
---
|
||||
|
||||
## 14. Suggested Collaboration Framing
|
||||
|
||||
This should be positioned as a tightly scoped exploration, not a large product
|
||||
commitment.
|
||||
|
||||
Suggested framing:
|
||||
|
||||
"Let's test one narrow wearable knowledge workflow where Legache supplies the
|
||||
local retrieval substrate and RSA supplies the bounded semantic interpretation
|
||||
layer. If the prototype shows strong latency and usability, that gives us a
|
||||
clear basis for deciding whether a broader wearable interface is worth building."
|
||||
Reference in New Issue
Block a user