Context Enrichment & Plant Memory

Classification accuracy comes from how much relevant context the LLM sees before it answers. This page covers the parts of the platform that build and maintain that context.

The retrieval pipeline, in plain terms

Before the LLM classifies a signal, the platform:

Pre-processes and translates the description — expanding domain abbreviations (see Vocabulary, below) and translating it into English IEC technical vocabulary while preserving numeric identifiers (unit numbers, sensor numbers, …).
Retrieves the most relevant supporting evidence from three vector collections: general Reference signals, previously Validated signals, and — if a plant is set — that plant's own PlantSignal_{rds_top_node} collection (see Plant Collections, below). Retrieval is hybrid (keyword + semantic) so exact codes and unit numbers aren't lost the way pure semantic search can lose them.
Reranks the candidates with a dedicated cross-encoder model before handing the short list to the classification step.

Signals retrieved from a plant's own history are trusted more than generic reference signals or other plants' validated signals — same-plant evidence is the strongest signal the pipeline has that a code is correct for this plant specifically.

Vocabulary

The Vocabulary page (sidebar → Config → Vocabulary, route /vocabulary) manages the two files the pre-processing step uses to expand domain abbreviations before translation:

single.txt — single-word abbreviations.
bigrams.txt — multi-word abbreviation pairs.

New to this page? Open the ⋯ menu at the top right (the one showing the app version) and choose Guided tour for a walkthrough of the two files, the entry format, and how saving is validated.

Both use the same format, one entry per line: key: value1, value2, … — where key is the canonical expansion and the comma-separated values are the abbreviations that should expand to it (e.g. Turbine: TB, TURB). The page is a full code editor with syntax highlighting; saving is blocked if a line doesn't match the key: value, value format, with the offending line number reported. There's no dedicated "add term" form or delete button — you edit the file's text directly, the same way you'd edit any line-delimited config file.

Vector DB Config

The Vector DB Config pages (sidebar → Config → Vector DB Config, routes /vector-db-config/master|reference|validated-signals|ontology) are sync and operations pages, not data browsers — you won't see individual records here. Each tab:

New to one of these tabs? Open the ⋯ menu at the top right (the one showing the app version) and choose Guided tour for a walkthrough of that tab's own connection card, collections card, and sync controls — each tab has its own tour, since Master also covers its wiki-regeneration button.

Shows the live connection status to both the SQL source and Weaviate.
Shows a Collections card listing what every collection currently holds. Three states are worth telling apart. Ingested shows the object count. Never ingested means no sync has ever run for that collection on this environment — it is not an error, and it is not visible anywhere else: retrieval simply returns nothing and classification carries on without it. Empty means a sync created the collection and left nothing in it, which is what a failed or half-finished run leaves behind — re-run the sync. A fourth state, Unknown, means Weaviate could not answer, which is never evidence that a sync is owed.
Lets you configure that tab's own SQL connection (host, port, database, credentials). Each source has its own connection: Master reads SQL Server while Reference and Validated Signals read PostgreSQL, so configuring one tab leaves the others untouched.
Offers Start Sync to pull current data from SQL into the matching Weaviate collection (Master = BL0/BL1/BL2 hierarchy from the MASTER table; Reference = reference signal library from refs.signals; Validated Signals = human-validated signals from the aspect.signal view, restricted to status = 'Validated'), with live progress shown as the sync streams.
Offers Recreate Collection — a destructive option that drops and rebuilds the collection from scratch before syncing; use it after a schema change, not for routine refreshes.

The Ontology tab is the exception to the pattern above: its source is not the SQL database but the RDF knowledge backend, so it has no connection form. It reads RDF_KNOWLEDGE_BACKEND_URL and RDF_KNOWLEDGE_BACKEND_API_KEY from the server environment, and Test connection simply checks that {URL}/docs answers 200. Start Sync downloads the whole ontology, parses it, turns every OWL entity (class, property, individual) into one OntologyChunk, and uploads them keyed by entity URI — so re-running without Recreate Collection updates existing entries in place instead of duplicating them. Changing the two environment variables requires an application restart to take effect.

Plant Collections

The Plant Collections page (sidebar → Config → Plant Collections, route /plant-collections) is where each plant's own validated-signal history lives — the PlantSignal_{rds_top_node} collection that the retrieval pipeline draws same-plant evidence from. Signals land here when you click Persist at the end of a supervised Classify Bulk run (see Classification Modes).

The sidebar lists every plant with saved signals and how many it holds; click one to open its panel (/plant-collections/{plant} deep-links directly to it). The panel header offers two actions:

Delete all — clears every signal for that plant.
Recreate collection — drops and rebuilds the collection from scratch; flagged with a warning since it's irreversible.

Below the header, a paginated table lists that plant's signals — description, full classified code, the BL0/BL1/BL2 breakdown, and the Logical Node class — with a delete button per row.

Building up this collection plant by plant is what lets future classifications for that same plant draw on its own corrected history, in addition to general reference and validated signals — the system gets more accurate for a plant the more it's used on that plant.