openrs-dcb

Embedding matching reaches the OpenRS request path

  • openrs
  • ors-appliance
  • resource-sharing
  • embeddings
  • metadata

Exact title matching is useful, but bibliographic descriptions vary. Punctuation, articles, transcription, title/subtitle boundaries and contributor forms can all obscure a plausible match. OpenRS now has a second, deliberately cautious route: an incoming supplier request can retrieve semantic candidates from the tenant’s catalogue and refer them for human review.

This is not an AI decision to supply. The first policy is referral-only. Rights, availability, carrier and fulfilment remain separate downstream questions, and embedding evidence alone cannot trigger automatic delivery.

Designed to change

The expensive mistake would be making today’s model part of the canonical record or Elasticsearch mapping. Instead, each enabled tenant gets a separate, versioned projection generation. Its identity includes the provider, model, immutable weights revision, dimensions and intellectual-view version. Changing any of those values creates a replacement while the current generation remains active. An alias switches only after the replacement backfill completes.

That shape lets matching improve without rebuilding the metadata registry. It also supports tenants that do not buy or want the capability: deployment configuration makes providers available, while a tenant Application Setting controls generation and retrieval. New tenants default enabled; existing tenants retain their prior behaviour until explicitly migrated.

The first projection uses BGE-M3 through the provider-neutral ORS embedding cache. The cache resolves the mutable model name to an immutable Ollama digest. Catalogue vectors are converted to 1,024 sign bits for Elasticsearch retrieval—128 bytes of vector payload per record rather than 4,096 bytes of 32-bit floats. Full catalogue vectors are not duplicated in the cache database; request citations may use a separate cache policy.

Continuous, not a one-off load

Backfill uses durable keyset cursors and bounded batches. A restart or provider outage resumes from the last completed batch. New, changed and deleted records use the same process, so enabling the capability does not introduce a special frozen catalogue or require a full reset.

Matching joins only a bounded candidate set back to current resource descriptions. It records scores, confidence bands and reasons, but does not store vectors in request history. If the provider or projection is unavailable, the embedding stage degrades and the existing exact path continues.

Evidence from a real request

The full local stack submitted a non-exact citation over ISO18626. The supplier workflow invoked the real resource matcher, retrieved the intended record among review candidates and persisted bounded supply-option evidence. The same smoke proved tenant disablement, cache reuse, provider outage, recovery and restart convergence.

This is a foundation, not a claim that record matching is solved. The useful result is an operational domain model that can absorb better views, quantisation, confidence calibration and reviewed examples without a catalogue reset or a frozen first-generation algorithm.