lorebit
  • English

      • Database and index adapters

      BOUNDARY · DATABASES ARE ADAPTERS, NOT THE PRODUCT

      lorebit is not trying to become a vector database. A database, search engine, graph store, or file system can provide a capability behind an adapter; lorebit's concern is the knowledge workflow that composes those capabilities.

      Choose capabilities, not a default database

      CapabilityQuestions to ask
      Source persistenceCan the original material and its version be retained and traced?
      Semantic retrievalCan relevant meaning be retrieved for a query?
      Lexical retrievalCan exact terminology, identifiers, and filters be found?
      RelationshipsCan useful links and hierarchy be traversed when needed?
      Rebuild checkpointsCan derived indexes be refreshed without losing the source record?

      An adopter may need one provider for all of these, or several providers. Both are valid if the adapter contract expresses what the workflow needs and keeps provider-specific choices localized.

      The stable boundary we are aiming for

      The public contract should describe observable capabilities and failure behavior, not force every consumer to adopt one storage engine. That keeps lorebit useful to DevCodex and to products with different operational constraints.

      No adapter API is published yet. Treat this page as an architectural decision record, not an integration reference.

      Next: preview status and public contract.