Corrections
When the AI says something wrong, a staff member rewrites it the way it should have been said. That rewrite is not a one-off fix to one conversation — after a reviewer approves it, the AI carries it forward and stops making the same mistake with every future customer. Status: LIVE end to end 0 corrections so far
flowchart TD
BOT["🤖 The AI sends a reply"] --> SPOT["🧑💼 A staff member reads it
in the Agent Inbox and
sees it is wrong"]
SPOT --> WRITE["They press Correct and write:
the better reply, what kind of
mistake it was, how serious,
and why it is wrong"]
WRITE --> PEND[("📥 Waiting for review")]
PEND --> REV{"A reviewer reads
the suggestion"}
REV -->|"reject"| NO["Kept for analytics.
Never taught to the AI."]
REV -->|"approve"| YES["✅ Approved"]
YES --> JOB["⚙️ The learning job
picks it up"]
JOB --> USE["The AI now carries the lesson
into every future conversation"]
classDef hi fill:#e7f2ec,stroke:#166b4e,color:#182420
class PEND,YES,USE hi
The full loop: spot → rewrite → human approval → the AI learns. Nothing reaches the AI without a reviewer saying yes.
1 · Spotting it — where a correction starts
Every message the AI sends sits in the Agent Inbox next to a Correct button. A staff member who sees a bad reply presses it and fills in four things:
The better reply — what the AI should have said, in the
words it should have used.
What kind of mistake — a wrong fact, the wrong tone, the
wrong language, a policy breach, and so on.
How serious — from a small slip to critical.
Why it is wrong — the reason, in the submitter's own words.
This is what a reviewer reads before deciding.
The system also quietly records which message was corrected and the surrounding conversation, so a reviewer weeks later can see the situation the AI was actually responding to rather than a rewrite floating in mid-air.
2 · Review — the gate that protects customers
A submitted correction is a suggestion. It changes nothing until a reviewer approves it, and that gate exists for a simple reason: an approved correction is taught to the AI and reaches real customers. One careless approval becomes everyone's answer.
| Who | What they can do |
|---|---|
| Any front-line agent (support, call agent) |
Submit corrections, and see their own submissions and stats. |
| Reviewers (admins and above by default) |
Approve or reject anything in the queue, and see every reviewer's queue and history. |
Review access is a permission, not a job title — it can be granted to any individual and taken away again, without changing their role. Admins and super-admins hold it by default.
3 · What an approved correction becomes
Approval hands the correction to a background job, which turns one rewrite into three different things — because a lesson is only useful if the AI can find it again at the right moment.
flowchart LR
OK["✅ One approved
correction"] --> A["🔎 Meaning fingerprint
stored for search"]
OK --> B["📌 Added to the
standing examples"]
OK --> C["🧪 Added to the
test set"]
A --> A2["When a future customer says
something similar, this exact
lesson is pulled up and shown
to the AI before it answers"]
B --> B2["Included in every complex
reply the AI writes, as a
worked example of the
right way to answer"]
C --> C2["Kept as a permanent check:
would today's AI still get
this one right?"]
classDef hi fill:#e7f2ec,stroke:#166b4e,color:#182420
class OK,A2,B2 hi
One approval, three destinations. The first two change what customers receive; the third guards against sliding backwards.
The first destination is the powerful one. The correction is stored as a meaning fingerprint rather than as text, so it is found by what the customer means, not the words they happen to use. A customer writing in Roman Urdu will pull up a correction originally written in English, as long as they are asking about the same thing.
Measured, not assumed. In an end-to-end test on the live system, a correction written in one phrasing was matched by a Roman-Urdu paraphrase at 88.5% similarity — comfortably above the bar required to be used, and the AI received it as guidance before writing its reply.
4 · How the AI carries the lesson forward — in detail
This is the part worth understanding properly, because it is not what most people assume. Nothing is retrained. The AI model itself never changes. What changes is what the AI is told at the moment it writes each reply.
Step one — the correction is stored by meaning, not by words
When a correction is approved, the situation it describes is converted into a meaning fingerprint: a long list of numbers that captures what the exchange was about. Two sentences that mean the same thing produce near-identical fingerprints even if they share no words at all, and even if one is English and the other Roman Urdu.
This is why the system works for real Pakistani customers. Nobody has to predict the phrasings people will use.
Step two — every incoming message is compared against them
flowchart LR
NEW["📱 New customer message
'kya mujhe rozana 10 rishtay
muft milen ge?'"] --> F1["Meaning fingerprint
of this message"]
PAST[("📚 Fingerprints of every
approved correction")] --> CMP
F1 --> CMP{"How close is the
nearest match?"}
CMP -->|"below the bar"| IGN["Ignored — this is a
different situation"]
CMP -->|"above the bar
(88.5% in our live test)"| HIT["✅ Correction retrieved"]
HIT --> BLOCK["Written into the agent's
thinking as WRONG / RIGHT"]
classDef hi fill:#e7f2ec,stroke:#166b4e,color:#182420
class HIT,BLOCK hi
The matching step, opened up. The bar is adjustable — raise it for fewer, more certain matches.
Step three — a worked example
This is the exact case run end to end against the live system:
| What the AI said (wrong) |
"Ji bilkul, aap ko rozana 10 rishtay bheje jayen ge bilkul muft mein." — promising 10 free proposals a day, which is not our policy. |
| What staff corrected it to |
"Rishtay aap ki preferences ke mutabiq bheje jaate hain — rozana ka koi fixed number nahin hai, aur membership fee alag hai." |
| A later customer asks |
"kya mujhe rozana 10 rishtay muft milen ge?" — different words, same underlying question. |
| Match strength | 88.5% — comfortably above the bar, so the correction is retrieved. |
| What the AI is handed |
A short block naming the wrong answer and the approved one, before it writes a single word. |
Closely related past correction
WRONG: Ji bilkul, aap ko rozana 10 rishtay bheje jayen
ge bilkul muft mein.
RIGHT: Rishtay aap ki preferences ke mutabiq bheje jaate
hain — rozana ka koi fixed number nahin hai, aur membership fee alag hai.
The AI does not paste that second line back. It writes a fresh, natural reply to the actual person in front of it — but it now knows the policy and the wording staff want. Guidance, not a script.
Step four — where this sits inside a reply
Zooming back out, here is the whole path a customer message takes, with the lookup in place. It happens on every message, in the moment before the AI writes — there is no overnight batch and no retraining wait, so a correction approved a minute ago applies to the very next customer:
flowchart TD
MSG["📱 Customer sends a message"] --> CTX["The agent gathers everything
it knows about this customer"]
CTX --> ASK{"Have we been corrected
on something like this?"}
ASK -->|"nothing close enough"| PLAIN["Answers normally"]
ASK -->|"yes — close match"| INJ["The lesson is placed into
the agent's thinking:
WRONG … / RIGHT …"]
INJ --> WRITE["✍️ Writes the reply
knowing which way to go"]
PLAIN --> WRITE
WRITE --> VOICE["🎭 The formatter
one persona, every reply"]
VOICE --> OUT["📤 Sent to the customer"]
classDef hi fill:#e7f2ec,stroke:#166b4e,color:#182420
class INJ,WRITE hi
The lookup is one step inside the normal reply path — not a separate process running somewhere else.
Step five — two delivery channels, doing different jobs
| Live lookup | Standing examples | |
|---|---|---|
| When it applies | Only when the customer's message closely matches that specific correction. | On every complex reply, regardless of topic. |
| What it teaches | "In this exact situation, here is the right answer." | "Here is the general standard of a good reply." |
| How many | A handful, picked per message by closeness. | A small fixed set — capped, because each one costs a little on every single message. |
| Grows with | Every approved correction, without limit. | The most recent approvals only, up to the cap. |
The two work together: the standing examples raise the baseline quality of every complex reply, while the live lookup catches the specific mistakes staff have already fixed once.
What this deliberately does not do
- It does not retrain the AI. No model is modified. That also means a bad correction can be undone instantly — remove it and the next message is unaffected.
- It does not overwrite the AI's judgement. A correction is context, weighed alongside the customer's profile, history, and the conversation so far.
- It does not leak across unrelated topics. A correction about payment wording will not surface in a conversation about matchmaking — the closeness bar prevents it.
- It does not need the same language. A correction written in English is found by a customer writing Roman Urdu, and the reverse.
5 · The controls
Everything here can be turned up, turned down, or switched off from the Settings tab on the Corrections page — no code change, no deployment:
| Control | What it does |
|---|---|
| Master switch | Turns the whole feature off — both the standing examples and the live lookup. |
| Live lookup | Whether the AI searches past corrections on each incoming message. |
| How many to pull | The maximum number of past corrections shown to the AI for one message. |
| How similar is similar enough | The bar a past correction must clear to be used at all. Raise it for fewer, more certain matches. |
| Standing example cap | How many corrections are permanently included in every complex reply. Each one costs a little on every message, so this is deliberately bounded. |
The states a correction can be in
| State | Meaning |
|---|---|
| Waiting | Submitted, not yet reviewed. No effect on customers. |
| Approved | A reviewer accepted it. Handed to the learning job. |
| In use | Processed and searchable. The only state that reaches a customer. |
| Rejected | Declined. Kept for analytics; never taught to the AI. |
| Withdrawn | The submitter pulled it back before a decision. |