Seed knowledge bases can contain documents, conversations, text blocks, media, people, and spaces distributed across multiple locations. As a knowledge base grows, users need more than contextual search. They need to:

Open something they already know exists but only partially remember.

Explore a topic across many documents.

This becomes especially important for large imported knowledge bases, such as CONAMA, which may contain more than 2,000 documents.

This document focuses on these needs and not on the many search functions used across the app, such as adding a link, opening a document, or adding a writer.

Problem

Traditional document search assumes that users know what they are looking for and can express it through the correct keywords.

In a large knowledge base, users often have a less precise need. They may remember:

A fragment of a sentence.

A general idea.

The author or organization.

An approximate publication date.

The space where the information may exist.

A related concept, but not the terminology used in the source.

Returning only document titles is insufficient. Users need to inspect passages, compare results, refine their search, and progressively narrow a large body of information.

Topic exploration creates a related but distinct problem. The user may not be looking for one definitive passage. They may want to understand everything the knowledge base contains about a subject, compare different positions, or identify recurring themes across many documents.

The search experience must therefore support both retrieval and exploration.

Goal and Customer Journey

Enable users to find and investigate information across large Seed knowledge bases, even when they do not know exactly where the information is located or how it was originally expressed.

Inspirations

Slack

User Stories

As a user, I want to search using words that are conceptually related to a passage so that I can recover information without remembering its exact language.

As a user, I want to scan many passage results without repeatedly opening and closing documents so that I can recognize the information I was looking for.

Ideas:

Passage results contain enough context to evaluate relevance.

The user can expand a passage inline.

The user can preview the source document without losing the result set.

Returning from a document preserves the query, filters, result position, and scroll state.

The user can open results in a side panel or new tab where supported.

As a user, I want to filter results using partial clues such as author, date, space, or content type so that I can narrow down a large result set.

Ideas of supported filters

Author.

Space.

Resource type.

Publication date.

Last modification date.

Document status.

Media type.

Language.

Attributes or ontology types, when available.

Local, joined, or remote source.

Ideas

Filters can be applied before or after entering a query.

Active filters remain clearly visible.

Filters can be removed individually.

The user can clear all filters.

Result counts update as filters change.

As a user, I want to search for a topic and see relevant passages from across the knowledge base so that I can understand how the topic is discussed.

Ideas

Results can be grouped by passage or by document.

The default result provides both passage relevance and document context.

Multiple matching passages from the same document can be expanded.

The system avoids filling the initial results with many nearly identical passages from one document.

The user can switch between Best Match and Newest.

As a user, I want to refine my search iteratively so that I can move from a broad topic to a useful body of information.

Ideas the user can:

Add or remove terms.

Apply filters.

Search within the current result set.

Exclude a term.

Restrict the search to a space or document.

Change the result type.

Change the sorting method.

Preserve the current search while opening a result.

Future Research: Agent-Assisted Search

Future research could explore how agents can extend search from information retrieval into guided investigation.

Users could ask natural-language questions about their knowledge base and delegate multi-step tasks such as reformulating queries, applying filters, inspecting passages, grouping evidence, and producing cited syntheses. Agent outputs should remain grounded in accessible sources, distinguish evidence from interpretation, expose the searches and filters used, and link citations directly to source passages.

Further research should also examine two possible outputs:

Research pages: editable Seed documents created from an investigation, with explicit provenance and source links.

Dynamic research views: structured, inspectable Queries generated by an agent and kept current as the knowledge base changes.

Agent-generated results should not become canonical automatically, and changes to the underlying evidence should never silently rewrite previously published syntheses.

Open Questions

What should be searched locally, remotely, or on demand?

Only locally

Should the default global search include remote resources that have not been synced?

Only local resources.

How should the interface communicate incomplete distributed-search coverage?

TBD

Should semantic search always be active or exposed as a selectable mode?

It must be selectable, as it consumes much more CPU.

How should ranking balance exact matching, semantic similarity, recency, and link relationships?

We can work on ranking in a future project.

Should people and spaces appear in the default blended result set or only for short navigation queries?

Can every temporary search be represented as a Seed Query object?

Which Query definitions can be embedded, shared, or published?

Should Agent Search results be private drafts by default?

How should an agent-generated synthesis be refreshed when its source Query changes?

Should the agent publish a new version, propose changes, or only notify the user that the evidence has changed?

Which result views belong in the first release: List, Passage List, Table, or Gallery?

Should Search history be local to a device, synchronized across an account, or stored as a private distributed object?

Should indexing extracted PDF, image, audio, and video content be part of Search or a separate ingestion capability?

How should Search represent multiple versions or canonical copies of the same document?