Similar tickets, without knowing the answers

An obvious function with an uncomfortable standard route

Similarity search across one's own ticket store is an obvious wish: before somebody investigates a problem from scratch for the third time, it would help to know that a very similar case was already solved three months ago. Technically this is usually implemented with so-called embeddings — mathematical representations of text that make it possible to search for "similar in meaning" rather than merely "identical in wording".

The usual route there leads through a cloud service: the entire ticket store is uploaded to an external system, converted into embeddings there and stored in a vector database that lies outside one's own control. For a tool whose whole purpose is the controlled handling of personal data, that would be the antithesis of everything else JiCo does — an additional, permanent store of data in somebody else's place, filled with exactly the material the PII gate is supposed to keep away from the model.

The difference: a local copy that has already been cleaned

JiCo's similarity search therefore starts somewhere else. Its basis is not the raw Jira store, but the local replica — the copy that JiCo creates for its own operation anyway, held redacted and encrypted. The search index is thus not built from uncleaned raw data, but from exactly the material that has already passed through the PII gate.

The actual computation — turning text into embeddings — runs exclusively locally, with a model provided specifically for this purpose and operated locally (bge-m3). There is no moment at which ticket content leaves the machine for this function, because neither the computation nor the index itself ever goes to an external service.

What it feels like in everyday use

From the point of view of a language model or the local chat, this shows up as a single, inconspicuous tool: jira_aehnliche_suchen. The index is not built automatically in the background, but through a deliberately triggered run — either by terminal command or through the panel under Operations, there including a trial search with which the quality can be checked in advance, and the option to empty the index completely if needed.

One detail that turns out to matter surprisingly often in practice: every hit of the similarity search shows not only the state of the ticket, but also how old the local copy it rests on is — "read locally n minutes ago". This statement prevents a quiet misunderstanding that can arise with any kind of search index: that a hit is mistaken for the current state, although it rests on a local copy that may already be somewhat older.

An index that grows along with the replica

After the actual build run, the index does not stand still. A background process continuously adds newly read tickets — up to 32 per pass — so that freshly added or newly re-read content ends up in the index over time by itself, without a complete new build run being necessary every time. Because the index is technically derived from the local replica, it can be emptied completely at any time in the panel under Operations › Data care, without anything being lost for good: the underlying replica remains, and the index itself is recalculated from it at the next synchronisation.

What this function deliberately does not do

A similarity search across a local index is no substitute for a live query against Jira, and it is not presented as one either. It answers the question "what similar thing has there been here before" — not the question "what is the current state of this particular ticket right now". For the latter, JiCo continues to read directly against Jira, with the familiar state check before every execution.

This deliberate separation is no accident: a similarity search that also tried to work as current live access would either have to recompute far too often in order to stay current, or would buy itself the possibility of false confidence. Staying clearly separated is the simpler and more honest solution here.

The real gain does not lie in the technology

The real difference from an ordinary cloud similarity search does not lie in the quality of the hits found — that depends above all on the model used, and local as well as cloud models keep developing here. The difference lies in where the computation happens and where the results stay: on your own machine, out of data that has already been redacted, without creating a new, permanent store of data in somebody else's place. For a company that wants to avoid exactly that, this is not a technical detail but the actual reason to choose this route.