Correcting an answer so it stays corrected

Every assistant eventually answers something badly - a missing condition, an out-of-date figure, a sentence that reads as a promise. What separates a product you keep from one you switch off is whether fixing it takes thirty seconds and stays fixed. This is how a correction works in Allinaa, and what it deliberately does not do.

1. The bad answer is flagged, where you found it

You read conversations in your own panel, so a wrong answer is found where it happened, with the question that produced it and the rest of the thread around it. That context matters: the same answer can be right for one question and wrong for another, and a correction made without the question is usually the wrong correction. Flagging it opens a correction with the exact exchange attached.

2. Somebody takes it for review

A correction is not applied by whoever flagged it. It is taken for review, which is the step that stops two people fixing the same thing in opposite directions and stops a well-meaning edit that contradicts your own terms. For a business on Standard, response improvements are part of the included maintenance time; on Premium your own administrator can do it. Either way one named person is accountable for the change.

3. The fix goes into the knowledge, not into a special case

This is the design decision that matters. A correction is not a rule bolted onto one question - it is an edit to the business information the assistant answers from, which means it fixes every future question that touches the same fact, including the ones nobody has asked yet. Correct "we deliver on Saturdays" once and the Saturday answer is right whether the next visitor asks about delivery, about weekend availability or about a specific date.

4. It becomes a new version, and the old one is kept

Applying a correction creates a new version of the knowledge rather than overwriting the old text. That gives you two things most products do not: you can see what changed and when, and you can see who changed it, because every management action is written to an audit trail. A change nobody can trace is how a business ends up with a chatbot saying something nobody remembers approving.

Unchanged text is rejected rather than saved as a new version, so the history is a list of real changes and not a log of people pressing save.

5. Check the answer, then mark it applied

The last step is to ask the question again and read what comes back. This is the step people skip, and it is the one that catches a correction that was right in intention and wrong in wording. Only then is the correction marked applied. If the answer is still wrong, you are in the same loop with better information rather than having closed a ticket.

What is deliberately not done

• History is never rewritten. The conversation where the wrong answer was given keeps the wrong answer. A record you can edit afterwards is not a record, and if a customer acted on what they were told, you need to be able to see exactly what they were told.
• Nothing is auto-applied. A suggested correction never reaches the live knowledge without a person approving it - not from a visitor, not from the assistant itself, not from a pattern in the data.
• A seed or template never silently replaces your approved text. Your knowledge is yours; it is replaced only by a deliberate, versioned change.

The questions it could not answer are your work queue

Corrections handle answers that were wrong. The other half is answers that never came: the assistant marks a conversation it could not finish, with the question it failed on, and your panel can filter to exactly those. In week one that list is long and valuable - most entries are one missing fact. Working through ten of them is the difference between an assistant that gets used and one that gets switched off. See what visitors asked for and how accurate a chatbot is.

Who should own this in your business

One person, ten minutes a week, reading the failed questions and the flagged answers. It does not need to be a technical person - it needs to be somebody who knows the true answers and is allowed to decide them. That is the whole job, and it is why the knowledge is written in plain sentences rather than in a configuration language. See what to put in the knowledge and chatbot best practices.