Knowledge store¶

The knowledge store is SPOT's shared memory of the organisation it is defending. Context providers deposit organisational facts into it on a schedule; analyzers consult it during analysis to check the email they are looking at against what the company actually knows. The two sides never talk to each other ; they share only the tag vocabulary used to label and look up documents.

This separation is what lets SPOT improve over time without changing its analyzers. Adding a new context provider ; an HR system, a partner-domain feed, a policy wiki ; instantly makes its data available to every analyzer that already knows how to read those tags.

What lives in it¶

A knowledge document is a small, self-contained piece of information that an analyzer can read. Typical examples:

An employee profile: name, role, department, email aliases.
A known partner domain and the kind of correspondence expected with it.
A policy paragraph: the rules around wire transfers, vendor changes, password resets.
A normalised fact extracted from a wiki, intranet, or HR system.

Documents are tagged. A profile for the CFO might carry the tags employee, executive, finance. A policy entry about wire transfers might carry policy, finance, wire-transfer. Analyzers query by tag expressions like executive+finance — documents that have both tags ; rather than by which provider produced them. This means the search never depends on the wiring; it depends on what the document is about.

flowchart LR
    P1[Employee directory<br/>provider]
    P2[Policy wiki<br/>provider]
    P3[Partner-domain<br/>provider]
    KB[(Knowledge store)]
    A1[Language-model<br/>analyzer]
    A2[Rules<br/>analyzer]

    P1 -->|tags: employee,<br/>executive| KB
    P2 -->|tags: policy,<br/>finance| KB
    P3 -->|tags: partner-domain,<br/>known-good| KB
    A1 -->|query<br/>executive+finance| KB
    A2 -->|query<br/>partner-domain| KB
    KB -.->|matching docs| A1
    KB -.->|matching docs| A2

How analyzers use it¶

When an analyzer looks at an email, it can ask the knowledge store for documents that are likely to be relevant. There are two flavours of query:

A semantic search: "find documents that look like this text". The analyzer hands over the part of the email it cares about (the body, a subject line, a sender name) and the store ranks documents by similarity.
A tag filter: "limit the results to documents tagged executive+finance". The analyzer narrows the universe of documents the search runs against.

Most analyzers combine the two: search the embedding space, but only inside the slice tagged executive. This is what lets a language-model analyzer notice that a "wire transfer" message is asking for an amount the policy book caps lower, or that the sender's name is almost one of the company's executives.

What an operator sees¶

The dashboard's Knowledge page is a direct window onto the store. Operators can:

See how many documents each provider has deposited and when it last synced.
Browse or search the store the same way an analyzer would, using the same tag expressions and the same semantic query.
Open a single document to see its content, its tags, its source provider, and when it was last updated.

Knowledge document detail page showing content, tags, source provider, last-updated timestamp, and the analyzers that have queried it — Knowledge document detail ; content, tags, source provider, and the analyzers that have queried it.

This view exists for two reasons. The first is verification: when an operator installs a new provider, they want to confirm its data arrived in the right shape and with the right tags before any analyzer relies on it. The second is investigation: when a classification looks wrong, the operator can check whether the knowledge the analyzer expected was actually present in the store at the time.

Sync and freshness¶

Each context provider runs on its own cadence, declared when the provider is installed. An employee directory might sync every six hours; a slow-changing policy wiki might sync once a day. The dashboard shows the last sync time and the next scheduled run for every installed provider, so an operator can tell at a glance whether the data is fresh.

Operators can also trigger a sync on demand from the provider's detail page ; useful right after a personnel change, or when a new partner domain needs to be live before the next scheduled run.

What the knowledge store is not¶

It is not a search engine for past emails ; that is what the Emails page is for. It is not a verdict cache ; every analysis runs afresh, and the store only holds organisational context. And it is not the place to record human notes on a single message; those belong in the analysis itself, where the audit trail lives.