Skip to content

PRD-004: Knowledge Base

Field Value
ID PRD-004
Title Knowledge Base
Status Draft
Owner Loryth Team
Created 2026-02-18

1. Problem Statement

Personal knowledge management is fragmented across note-taking apps, bookmarks, file storage, and wikis. Users build personal knowledge bases in tools like Notion or Obsidian, but these are either cloud-dependent (Notion) or local-only without server sync (Obsidian). Neither integrates with other productivity tools — your notes can't reference your tasks, and your documents don't link to your recipes or financial records.

Loryth's KB service provides a self-hosted, Markdown-first knowledge base with hierarchical folders, revision history, binary asset storage, internal linking with backlinks, and two-way sync for external editor integration.

2. Target Personas

Persona Priority Relevance
Self-Hosting Tinkerer Primary Personal wiki, technical notes, connected knowledge graph
Plugin Developer Secondary Builds sync integrations (e.g., Obsidian bridge)
Mindful Planner Secondary Saves recipes and health research notes

3. User Stories

ID Story Priority
US-KB-001 Create and edit documents Must
US-KB-002 Track document revisions Must
US-KB-003 Upload and manage assets Should
US-KB-004 Link documents internally Should
US-KB-005 Search across documents Must
US-KB-006 Sync with external tools Could
US-KB-007 Control access with roles Should

4. Functional Requirements

ID Requirement Priority
FR-1 Hierarchical entry tree (folders, documents, assets) with self-referencing parent_id Must
FR-2 Unique entry names per (space, parent) with cycle prevention Must
FR-3 Append-only document revisions storing Markdown content Must
FR-4 Binary asset storage in object storage (MinIO/S3) with asset revisions Should
FR-5 Canonical internal links (kb://doc/<uuid>, kb://asset/<uuid>) stable across renames Should
FR-6 Backlink tracking via DocumentLink records Should
FR-7 Full-text search across document content and titles Must
FR-8 Space-based multi-tenancy with Reader/Editor roles Should
FR-9 SyncRoot configuration for partial or full two-way sync via scope_entry_ids Could

5. Non-Functional Requirements

  • Full-text search must return results in under 300ms for knowledge bases up to 10,000 documents
  • Asset uploads must support files up to 100MB
  • Revision history must not be deletable (append-only for auditability)

6. Acceptance Criteria

  • User can create folders and documents in a hierarchical tree (FR-1, FR-2)
  • Every document edit creates a new revision viewable in history (FR-3)
  • Binary assets upload to object storage and are referenceable via canonical links (FR-4, FR-5)
  • Internal links resolve correctly after document renames or moves (FR-5)
  • Backlinks display all documents linking to the current document (FR-6)
  • Full-text search finds documents by content and title (FR-7)
  • Role-based access restricts editing to Editor role (FR-8)

7. Out of Scope

  • Real-time collaborative editing (Google Docs-style)
  • WYSIWYG rich text editor (Markdown source editing only)
  • Public/anonymous document sharing
  • Version diffing or merge conflict resolution UI

8. Traceability

Artifact Reference
Vision Vision — "document organization" as a core domain
Roadmap Release 0.2
TD TD-0002 — File Storage System
Stories KB Stories

9. Open Questions

  • Should search support advanced query syntax (boolean operators, field-specific filters)?
  • How should sync handle conflicts when both local and remote changed the same document?
  • Should KB support document templates for frequently created content types?

10. Changelog

Date Change
2026-02-18 Initial version