bill/whetstone_RSA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add RSA extraction bootstrap and working notes

Browse Source
This commit is contained in:
Bill Holcombe
2026-04-12 15:48:43 -06:00
parent 9b112b9675
commit 0253a92f28
11 changed files with 2572 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

135
docs/business_strategy_options.md Normal file
View File

@@ -0,0 +1,135 @@
# Business Strategy Options
This document is a working note, not a final decision.
The goal is to capture plausible strategic paths for `whetstone_RSA` while the
broader Whetstone portfolio is still taking shape.
---
## Option 1: Private-First / Paid Pilot Strategy
### Position
Keep the implementation and methodology private while validating demand through
selective partner conversations, demos, and paid pilot work.
### Why Choose This
- the implementation may be easy for well-resourced teams to replicate once the
architecture is fully legible
- the project may be more valuable as private know-how than as public code
- early leverage may come from speed, proof, and integration support rather than
broad adoption
### What This Optimizes For
- capturing direct value from early implementations
- private pilot engagements
- selective design partnerships
- preserving implementation advantage while the category is still young
### Risks
- lower public visibility
- slower ecosystem growth
- less community pull
- harder to establish category ownership in public
---
## Option 2: Open-Source Portfolio Strategy
### Position
Release `whetstone_RSA` as one open-source library in the broader Whetstone
portfolio, using it to build reputation, attract collaborators, and establish
Whetstone as a source of strong architectural ideas.
### Why Choose This
- `whetstone_RSA` is only one of several strong architectural patterns across the
Whetstone project family
- public exposure may be more valuable than trying to protect one library in
isolation
- open source can create trust, reach, and portfolio coherence
- the real long-term asset may be the broader Whetstone ecosystem, not just the
RSA implementation
### What This Optimizes For
- public recognition
- category association
- credibility with programmers and technical teams
- inbound opportunities such as collaborations, consulting, contracts, and
future product adoption
- positioning Whetstone as an open-source software company with a distinctive
systems-and-AI architecture philosophy
### What This Does **Not** Assume
- that RSA itself becomes the direct revenue engine
- that the library alone needs to be defensible as a business moat
- that open source guarantees monetization
### Strategic Framing
In this option:
- `whetstone_RSA` is a flagship library
- Whetstone is the larger brand
- monetization may come from the broader ecosystem:
- consulting
- integrations
- custom work
- future products
- related libraries and tools
### Risks
- larger companies may adopt or replicate the pattern quickly
- public explanation may accelerate competitive copying
- direct monetization from the library itself may be limited
### Why It Still Might Be Worth It
If the broader Whetstone portfolio contains many strong ideas, then publishing
RSA may be less about protecting one asset and more about proving that Whetstone
consistently produces valuable software concepts.
In that case, the upside is not just adoption of RSA itself. The upside is:
- reputation
- trust
- visibility
- portfolio legitimacy
- strategic surface area for future work
---
## Current Thinking
This decision does not need to be made immediately.
The practical stance for now can be:
- keep developing RSA
- keep refining how to present it
- treat both private-first and open-source-portfolio as live options
- make the release decision based on which broader Whetstone strategy becomes
more compelling
---
## Key Strategic Question
Is `whetstone_RSA` primarily:
- a monetizable private capability that should be protected early
or
- a high-signal open-source library that helps establish Whetstone as a company
and architectural voice?
The answer to that question should drive the release model.

117
docs/case_studies/whetstone_dsl_extraction_yield_snapshot.md Normal file
View File

@@ -0,0 +1,117 @@
# WhetstoneDSL Extraction Yield Snapshot
## Slice
Parser:
- `tools/extract_gate_rows.py`
Contracts:
- `semantic/rsa_gate_extraction_contracts_v0.json`
Input slice:
- first 50 run directories under
`CLionProjects/whetstone_DSL/logs/taskitem_runs`
Output:
- `semantic/extracted_gate_rows_slice.ndjson`
## Summary
Observed counts from the 50-run slice:
- runs processed: `50`
- tasks processed: `106`
- rows emitted: `424`
- rows with rejection flags: `330`
Per-gate emitted rows:
- `prereq_op_selector`: `106`
- `target_file_selection`: `106`
- `acceptance_command_selection`: `106`
- `required_tool_selection`: `106`
Per-gate rejected rows:
- `prereq_op_selector`: `12`
- `target_file_selection`: `106`
- `acceptance_command_selection`: `106`
- `required_tool_selection`: `106`
## Dominant Rejection Flags
- `sibling_uniform_target_files`: `106`
- `sibling_uniform_acceptance_commands`: `106`
- `sibling_uniform_required_tools`: `106`
- `invalid_prerequisite_values:whetstone_generate_taskitems,whetstone_queue_ready,whetstone_validate_taskitem`: `12`
## Interpretation
### `prereq_op_selector`
This is the strongest current extraction surface.
It survives most of the slice cleanly, and the rejection cases are informative
rather than noisy. The rejected rows come from schema-drift runs where
`prerequisiteOps` was contaminated with tool ids such as:
- `whetstone_generate_taskitems`
- `whetstone_queue_ready`
- `whetstone_validate_taskitem`
That means the parser is catching real label pollution rather than inventing
false negatives.
### `target_file_selection`
Present explicitly, but not yet trustworthy as broad supervision in this slice.
The dominant issue is sibling-uniform output: all tasks in a run often carry the
same target-file list, which makes naive extraction look more like template
reuse than local bounded choice.
### `acceptance_command_selection`
Present explicitly, but also highly template-like in this slice.
The same sibling-uniform pattern appears across runs, which suggests these rows
should remain review-gated until we either:
- find more diverse artifact families
- or factor the decision more tightly
### `required_tool_selection`
Same current status as acceptance commands.
The field exists and is easy to parse, but the observed slice suggests strong
template carryover rather than high-confidence local decision variance.
## Immediate Conclusion
The current first supervised RSA gate should be:
- `prereq_op_selector`
The following remain promising, but should stay review-gated or filtered more
aggressively before broader extraction:
- `target_file_selection`
- `acceptance_command_selection`
- `required_tool_selection`
## Next Steps
1. Tighten parser-side filtering for schema-drift prereq rows and optionally
split accepted vs rejected outputs.
2. Search for artifact families with higher local variance for:
- `target_file_selection`
- `acceptance_command_selection`
- `required_tool_selection`
3. Promote `prereq_op_selector` to the first extraction-ready gate dataset.

238
docs/legache_smartwatch_concept.md Normal file
View File

@@ -0,0 +1,238 @@
# Legache Smartwatch Concept
This note sketches a possible collaboration concept between `whetstone_RSA` and
Legache.
The goal is not "general AI on a watch."
The goal is a **bounded local knowledge interface** that can interpret short
voice or text requests, retrieve the right local information, and present fast,
useful results with local latency.
---
## Core Idea
If Legache already has:
- compact local document indexing
- strong metadata
- efficient retrieval
- structured organization of messy business information
then `whetstone_RSA` could sit on top of that as the **semantic interpretation
layer**.
In that architecture:
- Legache organizes and retrieves the right local knowledge
- RSA interprets the user's request into a bounded contract
- deterministic UI logic renders the response or action
---
## What The Watch App Would Actually Be
Not:
- a chatbot
- arbitrary long-form question answering
- open-ended reasoning over a large corpus
Instead:
- a fast local query bar
- a bounded voice-command interface
- a local knowledge lookup tool
- a semantic front-end for deterministic retrieval and display
---
## Example User Requests
- "What's our refund deadline?"
- "Who approves travel over two thousand dollars?"
- "Show the latest warehouse checklist."
- "Open the PTO policy."
- "Find the client note from yesterday."
These all have a useful bounded structure even if the phrasing is messy.
---
## Proposed Architecture
```text
synced local corpus + metadata
->
local retrieval / index lookup
->
RSA intent + slot interpretation
->
bounded answer contract
->
deterministic watch UI
```
Alternative flow:
```text
voice input
->
speech-to-text
->
RSA gate
->
retrieval + deterministic rendering
```
---
## What RSA Would Do
RSA would not try to "know everything in the documents."
RSA would help determine:
- what kind of request this is
- what data source or document family to search
- what entities or filters are being referenced
- whether the request is best handled as:
- exact lookup
- filtered search
- policy answer
- latest note/document retrieval
- escalation / low-confidence fallback
RSA could also fill a small structured contract such as:
- mode
- entity type
- search domain
- filters
- requested action
- confidence
---
## Why A Watch Is Interesting
A smartwatch is a good fit if:
- latency matters
- privacy matters
- the requests are short
- the answer space is bounded enough
- hands-free voice interaction is useful
That makes this especially interesting for:
- field operations
- executives
- support staff
- warehouse / logistics contexts
- personal enterprise knowledge access
---
## What Makes This Plausible
This becomes much more plausible if Legache already solves:
- document sync
- metadata extraction
- retrieval quality
- local indexing
In that case, the watch does **not** need to solve open-ended question answering.
It only needs to:
- interpret the request
- retrieve the right local subset
- render a bounded answer or action quickly
---
## Good MVP Scope
Start with one narrow workflow.
Examples:
- policy lookup
- latest-note retrieval
- checklist lookup
- contact/account ownership lookup
- recent event / report lookup
The MVP should:
- use local synced data
- support short voice/text requests
- map requests into a bounded contract
- retrieve and display results locally
---
## Bad MVP Scope
Avoid:
- arbitrary multi-document reasoning
- long-form answer generation
- freeform research assistant behavior
- "answer anything about the whole company"
Those stretch beyond the bounded local-watch value proposition.
---
## Why This Could Be A Good Collaboration
Legache appears to already own an important part of the stack:
- organizing messy information into compact usable local structure
RSA would complement that by supplying:
- semantic intent interpretation
- bounded contract generation
- confidence / abstain behavior
- a small-model path for local interaction
That means the collaboration is not redundant.
It is potentially additive:
- Legache: local knowledge substrate
- RSA: bounded semantic interface layer
---
## Suggested Positioning
If discussed with Legache, position this as:
**A smartwatch-scale local knowledge interface built on top of Legache's indexed
corpus, with RSA acting as the semantic interpretation layer for bounded voice or
text requests.**
This is stronger than saying:
"let me build a watch AI app."
It is more specific, more technical, and more defensible.
---
## MVP Pitch Shape
Suggested framing:
"If Legache already has efficient local indexing and retrieval, I think there may
be a strong fit for a smartwatch or wearable interface that uses bounded semantic
interpretation on top of that. The goal would not be open-ended AI on a watch. It
would be fast local lookup and action for short enterprise knowledge requests,
using RSA-style intent and slot interpretation to drive deterministic retrieval
and display."

305
docs/legache_smartwatch_mvp_proposal.md Normal file
View 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."