Why we stopped letting the AI work out a date

In early September someone asked our chat an entirely ordinary question: “Can you summarise next week's main committee meeting? Which items are relevant for us?”

The answer: the meeting was not in the archive.

It was. It had been for ten days — complete, with the agenda and every submission, more than five hundred passages in the index. Suspicion first fell on the import service that collects the data overnight. It was running perfectly, every 33 minutes, without complaint.

There were four faults. They sat in four different layers, had nothing to do with one another, and any single one of them would have been enough to ruin the answer.

Fault 1: “next week” is not an arithmetic problem

Before anything is searched, a model translates the question into a search request — including the time range. It turned “next week” into today plus seven days. The question was asked on a Tuesday, so the search began on the following Tuesday. The meeting was on a Monday. It fell out of the filter by exactly one day.

No hits. And therefore, from the system's point of view, correct: no data.

Fault 2: two quotation marks

Two of the council PDFs carried quotation marks in their titles. Handing them to the document processor broke the upload every single time — a detail of the transfer protocol that cannot cope with quotation marks in a file name. The import consequently reported “completed with errors” on every run.

That was not the cause of the problem, but it lengthened the search for it: the logs did contain a genuine error. It was simply a different one.

Fault 3: the model did not believe its own context

Once fault 1 was fixed, the right meeting was in the context — with its date, the agenda, fourteen passages, twenty-one sources. The answering model nevertheless worked out a date of its own, arrived at a different day, and declared the correctly supplied context empty.

The answer was no longer merely incomplete. It was wrong, and it sounded confident.

Fault 4: the repair that made things worse

The obvious move is to tell the model in its instructions what to do: “Trust the date given in the context. Do not calculate one yourself.” That is exactly what we tried.

It got worse.

A language model does not follow an instruction the way a program follows a condition. It weighs it — against everything else in the context, and against what its training suggests is plausible. A polite request is a weak force. When the model is small and answers without intermediate steps, the request loses reliably.

What we did instead

We removed the opportunity for error rather than asking the model to avoid it:

• Time ranges are calculated in code, not by the model. “This week”, “next week”, “next month” — the code works out Monday to Sunday and hands over finished dates. The model may use them; it does not derive them.
• The meeting date sits in the context together with its weekday. Not as a request, but as a header above the block of text: date, weekday, and for future appointments a marker identifying it as an upcoming meeting.
• For meeting questions the model thinks. Wherever a meeting block is involved, we switch on the slower, more careful mode. It costs seconds and saves wrong answers.
• File names are sanitised before they reach the transfer protocol. Umlauts and dashes stay; header-breaking characters go.

Every one of these changes is covered by tests — including the awkward cases: week boundaries, month boundaries, year boundaries. And the real file name it had failed on is now a test case in the code.

After that, the question returned the right meeting, with the correct date, the correct weekday and the actual agenda.

What we take from it

Hard facts belong in code, not in a request to the model. A date, an amount, a deadline, a responsibility — anything that can be determined unambiguously should be determined and handed over. The model is good at understanding language and expressing connections. It is not good at arithmetic, and it is unreliable at following rules that contradict its own judgement.

The second point is less comfortable: a single fault is rarely alone. Here four independent faults overlapped so neatly that the symptom looked like a broken import — and the import was the one part that worked. Stop at the first plausible suspicion and you repair the wrong thing.

We are writing this down because most of the talk about artificial intelligence is about what succeeds. A system becomes dependable in the places where somebody took the failures seriously enough to follow them to the end — and did not leave the solution to the model.