Getting a language model to answer in columns

PulseDesk reads incoming comments and files the ones that are real problems as tickets, with a category, a priority and a one-line summary already on them. A Llama-3-8B-Instruct call does the judging.

Almost none of the code is about the model.

The seam

There is exactly one class that knows an LLM exists — HuggingFaceService — and its whole job is to hand back something that is already data:

• ticketWorthy — a boolean
• category — BUG, FEATURE, BILLING, ACCOUNT or OTHER
• priority — LOW, MEDIUM or HIGH
• summary — one line

CommentService sees a decision. TicketRepository sees a row. Neither has an opinion about where it came from, and both would keep working if the model were replaced by a rules engine or a person.

Why that shape and not prose

A model asked an open question answers in prose, and prose is not a column. Worse, it is nearly a column — it will give you "Priority: High (though this depends...)" and the parser that was fine for a week starts producing nulls in production.

So the prompt asks for a closed set and the parser refuses anything outside it. If the answer does not fit the enum, the comment is simply not made into a ticket. That is a much better failure than a ticket with a priority of HIGH (probably).

Constrain the output where you parse it, not only where you ask for it. The prompt is a request; the parser is the contract.

The boring frame

Controllers, services, repositories, JPA entities — deliberately ordinary. The unfamiliar part of this system is one HTTP call to a model, and the way to keep an unfamiliar part reviewable is to surround it with parts nobody has to think about.

Storage is H2 in memory, which is the right answer for a demonstrator: something that needs a database installed before it will start is something nobody will run.