How the model knows what a defect is

A misunderstanding that does not feel like one

Anyone who has ever moved between two companies knows the small culture shock: what is called a "defect" here was called a "bug" there, and what passed as a "change request" there would have been unthinkable here as an issue type of its own. People usually learn such differences within a few weeks, often without consciously noticing — they ask, they observe how colleagues use the terms, and they adapt.

A generic language model has no such opportunity to learn. It knows the general meaning of "defect" from its training data, but not the specific definition that applies in this one particular Jira project — and unlike with a person, such a misunderstanding does not necessarily stand out. A confidently phrased proposal that rests on the wrong meaning of a technical term often reads, in the end, just as convincingly as a correct one.

A glossary that grows out of real data instead of being invented

JiCo meets this problem by not having a glossary invented by hand, but building it from the actual metadata of the connected Jira — issue types, field values, selection lists, as they really occur in the specific installation, not as a generic template. A complete entry carries more than just a term: the preferred expression, permitted abbreviations, synonyms including outdated spellings that are resolved and replaced automatically, opposing terms and a short explanation.

Particularly effective here are the explicit demarcations — entries of the form "defect NOT: change request". That phrasing sounds unremarkable, but it hits the heart of the original problem: a model that only knows what a term means can still be wrong if it does not also know what the term explicitly does not mean — especially in the places where two terms are easily confused in everyday use.

When a question remains ambiguous, that is said

Not every ambiguity can be resolved in advance by a glossary. JiCo therefore additionally keeps a query vocabulary of its own, which records how an everyday term is translated into a concrete Jira query — and whether that translation is unambiguous or rests on an assumption. If a request remains ambiguous, because it is unclear which of two similar-sounding fields was meant, for instance, this note appears directly in the answer instead of an assumption being made silently and presented as a supposedly certain answer.

(Addendum 2026-10-10: the six deterministic quick questions described here belonged to JiCo's own chat and were removed with it, JICO-D-1969. JiCo no longer appends the note about an assumption to the answer either — that would require seeing the answer, and the answer stays with the AI client. The query vocabulary itself remains: it sits in the model context and asks the model to name the restriction it used.)

Conventions that live in a repository rather than in the code

Besides the pure vocabulary, JiCo also knows professional conventions — rules of the form "if a ticket is set to 'done', field X must be filled in as well". These rules deliberately do not sit hard-wired in the program code, but in an exchangeable file from a repository: either from the public standard repository, which is preconfigured for the general case, or from a company-specific one. This single file is checked strictly, fetched again automatically every day, and every change is recorded in the audit trail.

This has a practical advantage that only shows itself in daily use: if a professional rule changes because a team adjusts its process, nobody has to modify JiCo itself or wait for an update — the one conventions file is adjusted, and the next automatic synchronisation adopts the new rule by itself. Rules can even be restricted to individual projects when different teams maintain different conventions.

Custom fields do not stay anonymous either

The same principle applies to the many company-specific additional fields with which almost every real Jira installation goes beyond the standard fields. For these JiCo keeps a field catalogue of its own, which knows, for every technical field name, the matching JQL name, the actual type and — for selection fields — the exactly valid values together with their abbreviations. If somebody asks for a value that in truth does not exist, JiCo rejects the search with the values that are actually valid, instead of sending off a query that would come back empty without anyone understanding why. Deliberately left out of this are free-text and person fields — for them the PII gate continues to apply, not the field catalogue, because a free text field cannot be reduced to a fixed list of values.

The real benefit lies before the answer, not in it

The decisive effect of all these building blocks does not show in answers being more nicely phrased in the end, but in where in the sequence they take hold: terms are already unified within the model context itself — before a proposal even comes into being — and a second time directly in the written proposal, before it is put before a human for approval. A misunderstanding about a technical term is thus meant, as far as possible, never to enter a finished proposal in the first place, rather than having to be discovered laboriously afterwards.