Common Library
Entity Repositories
common holds the repositories that are not engine-specific: the evaluation and access-control
queries, and the Elasticsearch vector search implementation that memory is built on. The engine’s
own repositories are listed in Data Access.
Repository interfaces are discovered by the consuming application’s @Enable*Repositories
declarations over ai.promethist.**.repository.
MongoDB
| Repository | Queries |
|---|---|
Evaluation definitions by IDs, by project, by test mode, and by ref and state. |
|
Insight groups of an evaluation. |
|
Insight definitions with a fallback match, so an insight can be declared independently of a
specific evaluation or project and still apply, ordered by its |
|
The project’s codebook entries, by project and by name. |
|
Coded occurrences by project and user, the lookup that skips an already-classified subject, and the atomic claim that hands one growth pass a batch of unclassified texts without a second pass taking the same ones. |
|
One profile per project and user. |
|
The reporting queries. Aggregation pipelines join results with their definitions and filter by combinations of user, project, agent ref, session, execution mode and time range — this is what backs the insight and aggregation endpoints. |
|
Evaluation results by session, user and project, optionally within a time range. |
|
Feedback definitions by project, and by ID within a project. |
|
Question definitions by IDs and by project. |
|
Feedback by session, definition and project; a user’s latest request of a definition revision,
and the latest one with an answer to a given set of questions; and the existence checks for an
answered and for a skipped feedback over all the revisions of a definition, given as their ids, which
repeat the conditions of the derived |
|
Access control records by tenant, project and user. |
|
Billing details by tenant and by payment provider customer ID. |
|
Pricing details by tenant. |
|
Chat history documents. |
|
MCP connectors, by ref. |
|
Audit events. |
Two styles appear: ReactiveMongoRepository where Mongo-specific @Query or @Aggregation
annotations are needed, and the plainer ReactiveCrudRepository where derived queries suffice.
Elasticsearch
Vector search is not expressible as a derived query, so it is implemented by hand.
interface ElasticsearchRepository<T : TextuallyRepresented> :
ReactiveElasticsearchRepository<T, ID>,
ElasticsearchRepositoryCustom<T>
ElasticsearchRepositoryCustom adds the operations memory relies on:
| Operation | Purpose |
|---|---|
|
Cosine similarity search returning the score with each hit. |
|
The same, restricted by metadata (namespace, user, agent, time). |
|
The most recent unit for a field whose name is not known at compile time. |
|
Units created within an interval. |
|
Reading and erasing one scope of one user’s memory — what memory deletion uses. |
|
Indexing a document, and forcing a refresh so a just-written unit is immediately searchable. |
ElasticsearchRepositoryImpl implements them on ReactiveElasticsearchOperations with native
queries, similarity implemented as a script score, and a single retry on timeout that is then
surfaced as a knowledge search timeout — a slow search degrades the answer rather than failing the
conversation.