Skip to content

paszed/search

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 

Repository files navigation

Search

Reusable infrastructure for indexing, retrieval, ranking, and discovery.

Search provides shared capabilities for making structured information discoverable across applications and systems.

Rather than implementing retrieval independently inside every application, this repository centralizes search behavior behind composable primitives and well-defined interfaces.

Its purpose is to make search a reusable platform capability rather than an application-specific feature.


Why

Search becomes significantly more complex as applications grow.

Content needs to be indexed.

Queries need to be interpreted.

Results need to be ranked.

Matches need to be highlighted.

Filters and facets need to remain predictable.

Different retrieval strategies need to coexist.

Reimplementing these capabilities in every application creates duplicated logic, inconsistent ranking behavior, and tightly coupled search experiences.

Search exists to provide those capabilities once, behind stable boundaries.


Scope

Search may include:

  • Document indexing
  • Query processing
  • Full-text search
  • Fuzzy matching
  • Match highlighting
  • Result ranking
  • Result grouping
  • Filtering
  • Faceted search
  • Search adapters
  • Search providers
  • Query normalization
  • Search analytics
  • Retrieval strategies
  • Semantic search
  • Vector search
  • Hybrid retrieval
  • Reranking

Repository Structure

```text search/ ├── adapters/ ├── analytics/ ├── highlighting/ ├── indexing/ ├── providers/ ├── query/ ├── ranking/ ├── retrieval/ └── utils/ ```

The structure will evolve as additional retrieval and discovery capabilities are introduced.


Design Philosophy

Search should remain:

  • Fast
  • Predictable
  • Typed
  • Composable
  • Framework-agnostic
  • Provider-agnostic
  • Observable
  • Extensible
  • Easy to integrate

Applications should provide information and presentation.

Search should make that information discoverable.


Architecture

Search separates the major stages of information retrieval.

```text Source Data │ ▼ Normalization │ ▼ Indexing │ ▼ Query Processing │ ▼ Retrieval │ ▼ Ranking │ ▼ Results ```

Each stage should remain independently replaceable where practical.

A small application may use an in-memory index and lexical ranking.

A larger system may use an external search provider, vector retrieval, or hybrid ranking.

Consumers should not need to redesign their application around the underlying search implementation.


Boundaries

Search owns retrieval and discovery behavior.

It does not own the source data or the interface used to present results.

For example:

  • Content Engine may produce normalized searchable documents.
  • Search indexes, retrieves, and ranks those documents.
  • Design System provides reusable presentation primitives.
  • Applications compose those capabilities into their final search experience.

This keeps indexing, retrieval, and ranking independent from content processing and interface architecture.


Non-Goals

Search intentionally does not contain:

  • Application pages
  • General-purpose UI components
  • Content authoring or publishing
  • Application-specific domain models
  • Authentication or authorization
  • Business logic
  • Deployment infrastructure

Those capabilities belong in their respective repositories.


Ecosystem

Search is a reusable capability within the broader ecosystem.

It can integrate with:

  • Content Engine — Structured and normalized content
  • Design System — Presentation of search experiences
  • Data Platform — Searchable data from connected sources
  • Agent Network — Retrieval capabilities for agents
  • Identity — Access-aware retrieval
  • Observability — Query diagnostics, performance, and telemetry
  • Testkit — Shared testing infrastructure
  • Bootstrapper — Project scaffolding and integration

Applications such as paszed.me can consume Search without owning their own retrieval infrastructure.


Evolution

Search should support increasing sophistication without requiring consumers to adopt it all at once.

```text Lexical Search │ ▼ Fuzzy Retrieval │ ▼ Advanced Ranking │ ▼ Semantic Retrieval │ ▼ Hybrid Search │ ▼ Agentic Retrieval ```

Simple consumers should remain simple.

Advanced retrieval should be additive rather than requiring architectural replacement.


Long-Term Vision

The long-term goal is to provide a complete retrieval foundation capable of supporting everything from small static websites to large applications and AI systems.

Future capabilities may include semantic retrieval, vector search, hybrid ranking, reranking, query expansion, personalization, and agent-assisted discovery.

These capabilities should integrate behind stable contracts without compromising the repository's core architecture.

Search should remain a capability, not become an application.


Status

Search is under active development.

Its architecture will evolve from concrete retrieval requirements across consuming systems rather than speculative abstraction.


License

Licensed under the MIT License.

About

Search, retrieval, ranking, and discovery infrastructure

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors