Update planning package after Phase 0B
This commit is contained in:
JesseMarkowitz
@@ -1,6 +1,6 @@
|
||||
# Adventure Storyteller — Imported Knowledge Design
|
||||
|
||||
**Status:** Draft v0.1
|
||||
**Status:** v1.0 — selected implementation direction after Phase 0B
|
||||
**Purpose:** Define how local user-supplied knowledge is imported, classified, indexed, retrieved, inspected, disabled, deleted, and kept separate from executable instructions.
|
||||
|
||||
## 1. Design Goal
|
||||
@@ -949,16 +949,11 @@ For v1, plain metadata is sufficient.
|
||||
|
||||
## 65. Campaign-Wide vs Shared Library
|
||||
|
||||
Open question:
|
||||
V1 decision:
|
||||
|
||||
Should a source belong to:
|
||||
- one campaign only,
|
||||
or
|
||||
- reusable global library?
|
||||
> **Knowledge sources are campaign-scoped.**
|
||||
|
||||
Current recommendation for v1:
|
||||
|
||||
> Campaign-scoped knowledge first.
|
||||
A reusable global/shareable library may be considered later, but it is not part of the v1 storage or authority model.
|
||||
|
||||
Reasons:
|
||||
- simpler privacy model,
|
||||
@@ -1082,31 +1077,52 @@ These should be used to test:
|
||||
- disable/delete,
|
||||
- export/import.
|
||||
|
||||
## 73. Candidate Evaluation Questions
|
||||
## 73. Phase 0B Integration Decision
|
||||
|
||||
Codex should answer for AI-DnD:
|
||||
The production base is AI-DnD, but its Story Cards are **not** the production imported-knowledge store.
|
||||
|
||||
1. Can Story Cards map cleanly to Canon/Reference/Inspiration?
|
||||
2. Are cards campaign-scoped?
|
||||
3. How are cards chunked/retrieved?
|
||||
4. Can remote/provider dependencies be removed?
|
||||
5. Can provenance be shown per retrieved card/chunk?
|
||||
6. Can hidden canon be represented?
|
||||
7. Can local embeddings work fully offline?
|
||||
Phase 0B found that Story Cards do not carry the lineage/provenance structure required for a general imported-knowledge system and do not directly provide the required source classification, chunking, local FTS, semantic indexing, source lifecycle, and inspection model.
|
||||
|
||||
For Open Dungeon:
|
||||
Implement imported knowledge as separate first-class tables/services.
|
||||
|
||||
1. Does it currently support imported documents beyond built-in story data?
|
||||
2. What new storage/index layer would be required?
|
||||
3. Can its local image/story architecture remain separate from knowledge retrieval?
|
||||
4. What is the simplest local FTS/embedding integration?
|
||||
Recommended conceptual records:
|
||||
|
||||
For ai-adventure:
|
||||
```text
|
||||
knowledge_source
|
||||
knowledge_source_version (optional if v1 keeps simpler version metadata)
|
||||
knowledge_chunk
|
||||
knowledge_embedding / vector representation
|
||||
knowledge_retrieval_record
|
||||
```
|
||||
|
||||
1. Can the FTS lore system represent classifications?
|
||||
2. Can lore entries retain source provenance?
|
||||
3. How difficult is semantic retrieval addition?
|
||||
4. Is campaign isolation already strong?
|
||||
Every source/chunk must retain enough metadata for:
|
||||
|
||||
- campaign scope,
|
||||
- Canon / Reference / Inspiration class,
|
||||
- source provenance/hash,
|
||||
- enable/disable/delete,
|
||||
- chunk identity,
|
||||
- lexical/semantic retrieval,
|
||||
- prompt inspection,
|
||||
- export/import.
|
||||
|
||||
Normal imported files are campaign-level source material and need not inherit story-branch lineage merely because the story branches. If a future knowledge source or chunk is **derived from story history**, it must carry source turn/lineage coordinates so abandoned-path material cannot leak into active context.
|
||||
|
||||
Story Cards may remain as an inherited authored-rule/lore primitive during migration if useful, but they must not become an alternate untracked path around the new knowledge authority/provenance rules.
|
||||
|
||||
### Retrieval implementation direction
|
||||
|
||||
Use:
|
||||
|
||||
```text
|
||||
SQLite FTS5 lexical retrieval
|
||||
+
|
||||
local Ollama semantic embeddings where enabled
|
||||
+
|
||||
authority/relevance reranking
|
||||
```
|
||||
|
||||
Lexical retrieval remains available even if embeddings fail or are disabled.
|
||||
|
||||
## 74. V1 Acceptance Criteria
|
||||
|
||||
@@ -1123,16 +1139,19 @@ The final v1 must support:
|
||||
- bounded retrieval,
|
||||
- canon precedence,
|
||||
- no automatic URL fetch,
|
||||
- no remote image fetch,
|
||||
- no script execution,
|
||||
- prompt-injection framing as untrusted data,
|
||||
- export/import preservation.
|
||||
|
||||
Strongly preferred:
|
||||
Strongly preferred and planned for v1:
|
||||
|
||||
- lexical + semantic hybrid retrieval,
|
||||
- hidden/narrator-only canon,
|
||||
- source inspector,
|
||||
- prompt retrieval inspector.
|
||||
|
||||
## 75. Current Recommendation
|
||||
## 75. Selected Implementation
|
||||
|
||||
Implement imported knowledge as a first-class local subsystem:
|
||||
|
||||
@@ -1140,17 +1159,17 @@ Implement imported knowledge as a first-class local subsystem:
|
||||
Local File
|
||||
|
|
||||
v
|
||||
Validate
|
||||
Validate / Copy Locally / Hash
|
||||
|
|
||||
v
|
||||
Classify
|
||||
|
|
||||
v
|
||||
Chunk
|
||||
Chunk + Provenance
|
||||
|
|
||||
+--> SQLite FTS
|
||||
+--> SQLite FTS5
|
||||
|
|
||||
+--> Local Embeddings
|
||||
+--> Local Ollama Embeddings
|
||||
|
|
||||
v
|
||||
Hybrid Retrieval
|
||||
@@ -1162,7 +1181,7 @@ Authority Filter / Rerank
|
||||
Bounded Prompt Context
|
||||
```
|
||||
|
||||
And preserve this separation:
|
||||
Preserve this separation:
|
||||
|
||||
```text
|
||||
Story authority
|
||||
|
||||
Reference in New Issue
Block a user