VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

How Superintelligence Works | Feedback Loops — How AI Uses Corrections Without Repeating Mistakes

How does superintelligence work when an AI gets an answer wrong and someone corrects it? A user may point out an error, the assistant may rewrite the answer, and the conversation may look like a successful learning experience. But correcting one response, changing a system’s stored rules and training a model are different operations. Confusing them creates the impression that an AI has permanently learned something merely because it apologised or produced a better paragraph.

This guide explains feedback loops, revision, regression testing and verified correction in easy language. A feedback loop observes a result, compares it with a goal, makes an adjustment and checks whether the adjustment improved the outcome. A trustworthy AI application must also watch for changes that introduce new mistakes while trying to repair old ones.

We use a fictional school science-answer checker with twelve outputs, four initial errors, three first-pass fixes and one new regression. Every case and score is invented for education, not observed performance of a commercial AI system. The series title “How Superintelligence Works” does not claim current AI products have achieved artificial superintelligence.

1. What feedback means in everyday language

Feedback is information about what happened after an action. A pupil writes an explanation, a teacher identifies a missing step, and the pupil revises the answer. The teacher’s correction helps the pupil compare the current work with the intended standard.

An AI application can use an analogous process: generate an output, inspect it against a reference, locate an error, revise it and verify the result. The key is that somebody or something must supply trustworthy evidence of correctness. A model’s confident rewrite is not automatically a verified improvement.

2. A loop is more than a one-time comment

One comment says “This answer is wrong.” A feedback loop includes the next steps: determine why it is wrong, choose a repair, apply the repair, measure the new result and decide whether further correction is needed.

If the system stops after promising to improve, it has not completed the loop. If it repeats the same answer without checking, it may produce motion without progress. The verification stage is what closes the cycle.

3. Three kinds of correction should be kept separate

Response-level correction changes the current document or message. Workflow correction changes an external rule, prompt, parser, retrieval source or validation step. Model training changes learned parameters through a separate training procedure.

These may all improve an application under some conditions, but they do not happen automatically as one inseparable event. Editing a paragraph in WordPress does not prove that the underlying language model has been retrained. A useful system reports which layer actually changed.

4. Why this distinction matters to trust

An assistant might say “I will remember this correction” in a conversational way, but the application’s memory and training arrangements may be more limited. Users should not infer a permanent update from the wording alone.

Likewise, correcting the current article does not necessarily fix the same error in a different article. Reliable improvement requires carrying the relevant correction to the appropriate place and then checking the affected outputs.

5. The role of a trustworthy reference

Before calling something wrong, the checker needs a sound standard: a verified textbook result, an approved source, a deterministic calculation or a knowledgeable reviewer using a clear rubric. A model can propose a correction, but it cannot make an unsupported fact true by restating it with confidence.

Reviewers may also disagree. A transparent system records the evidence, the claim being tested and how a dispute was resolved. Feedback quality matters as much as feedback quantity.

6. A fictional Cedar Science Answer Desk

Imagine a school preparing twelve short science explanations, labelled A1 through A12. An independent reviewer checks them against a written answer key and confirmed source passages. Eight outputs are initially correct and four contain substantive mistakes.

The incorrect items are A2, A5, A9 and A12. The other eight are correct under the toy rubric. The task is to repair all four without altering the correct material. No actual pupil submissions, science grades or AI-service results are involved.

7. The initial twelve-output ledger

  • Initial outputs: 12.
  • Correct under independent review: A1, A3, A4, A6, A7, A8, A10, A11 — eight.
  • Incorrect under independent review: A2, A5, A9, A12 — four.
  • Initial verified correctness: 8/12 ≈ 66.7%.
  • Initial verified error count: 4.
  • Goal: correct the four errors while preserving the eight already-correct answers.
  • Important: the reference key is fixed during this toy exercise.

8. The first proposed repair

Suppose an editor revises A2, A5 and A9 using the reviewer’s notes and the approved answer key. The editor does not finish the correction to A12, which remains wrong. Three of the four original defects have therefore been addressed.

If the process measured only the number of edited entries, it might report success prematurely. We also need to ask whether the edits changed anything else and whether each corrected answer now passes a fresh check.

9. A regression appears in an earlier good answer

During the same first-pass edit, the editor unintentionally changes A7, which had been correct, so that its explanation now contradicts the reference. This is a regression: a previously correct result becomes incorrect after an attempted improvement.

The regression makes the new state different from the optimistic picture of three repaired errors and only one remaining. It demonstrates why changing an answer can introduce a problem elsewhere, even when the intention is to correct something.

10. Count the first-pass results

The original four errors were A2, A5, A9 and A12. Three are now corrected. A12 remains incorrect. A7 is newly incorrect. Thus the first revised set has two errors: A7 and A12.

Of the initial eight correct items, one regressed, leaving seven still correct. The three repaired items add three correct answers, making ten correct out of twelve. The new score is 10/12 ≈ 83.3%. That is a net gain of two correct results, not three, because one correct result was lost.

11. The repair ledger must reconcile

Start with four errors. Subtract three verified repairs. Add one new regression. The resulting error count is 4 − 3 + 1 = 2. That matches the two identified incorrect cases A7 and A12.

This simple equation illustrates the principle that repair progress must be measured net of new damage. Editing three wrong paragraphs does not mean the system is three errors closer to its target when one unrelated paragraph becomes wrong.

12. The final targeted repair

Suppose the editor checks A7 against its original correct version and restores the accurate explanation. The editor also completes the correction to A12, then reruns the entire twelve-item check. The reference reviewer confirms all twelve now meet the frozen rubric.

The result for this exact edited packet is 12/12 correct. That does not establish that the model has become universally reliable or that it will answer unseen science questions correctly. It establishes only that the twelve specified outputs passed this local review after the final corrections.

13. Three states of one invented correction cycle

  • Original: eight correct, four incorrect.
  • First revision: three original errors repaired.
  • Unresolved after first revision: A12.
  • New regression after first revision: A7.
  • First-revision total: ten correct, two incorrect.
  • Final revision: A7 restored and A12 corrected.
  • Final checked packet: twelve correct, zero incorrect.
  • What changed: edited content, not a documented model-training procedure.
  • What remains unknown: performance on new unseen tasks.

14. Why a claim of “self-learning” may be overstated

If the editor fixes a webpage and an assistant later quotes that improved webpage, the application may give a better response because its source changed. That does not prove the language model’s weights learned the correction. It may simply be retrieving better information.

Similarly, changing a prompt or validation script can alter output behaviour without retraining the model. The mechanism matters when evaluating what actually improved and whether the change will remain effective.

15. A correction needs a receipt

A trustworthy workflow records which claim was wrong, which evidence contradicted it, who approved the repair, what changed, when the revised output was saved and whether the final check passed.

In a publishing workflow, there is also a difference between a corrected draft and a verified live article. The assistant should not report the public page corrected until the content-management system confirms the update and the saved content has been checked.

16. Feedback can be immediate or delayed

A tutor may correct a pupil immediately after an answer. A software system may receive a bug report days later. An AI recommendation might produce an outcome that is not observed for weeks. Delayed feedback creates challenges: the surrounding situation may have changed and the evidence may be incomplete.

An application should not automatically treat a lack of feedback as proof of success. Silence may mean the user accepted the result, never saw it or did not have time to report the problem.

17. Why a thumbs-up is not a ground-truth label

A user may like an explanation because it is friendly and short while its factual content is wrong. Another user may dislike a correct answer because it is lengthy or inconvenient. Satisfaction is useful feedback, but it is not interchangeable with independently checked factual correctness.

For education, a good evaluation may combine user experience with answer verification and actual learner outcomes. Each measure answers a different question.

18. Feedback loops can reinforce mistakes

Imagine a recommendation tool mostly shows one type of resource. Users then click those visible resources, and the system treats clicks as evidence that the type is best. It could become more confident in a narrow selection partly because of its own earlier choices.

Such self-reinforcing effects require careful evaluation. The system should distinguish behaviour caused by what it chose to display from independent evidence of usefulness. User feedback is not always an unbiased sample of all possible options.

19. A correction can have a wider impact

Suppose an assistant uses one incorrect definition across ten connected lessons. Fixing the definition in one lesson is useful but may leave nine others with the original error. A change-impact review identifies dependent content that should also be checked.

The goal is not to rewrite everything unnecessarily. It is to trace the shared concept, locate affected statements and verify each relevant copy. This is how a local correction becomes a disciplined system repair.

20. Why the denominator must stay stable

If the initial set contains twelve outputs but the revised score reports only the ten easiest outputs, the apparent improvement is misleading. Both evaluations should cover the same twelve-item packet when we are comparing progress on those items.

A separate test set can measure transfer, but its size and difficulty must be reported. Passing a smaller or easier set does not prove that the original errors were repaired.

21. Sixteen claims about the toy feedback loop

Use the labels SUPPORTED, CONTRADICTED and NOT ESTABLISHED. The claims refer to the stated twelve-output record and its two revisions. Conclusions about retraining, unseen questions and real-world costs require evidence outside the toy fixture.

This helps distinguish exact arithmetic from plausible claims about what the system learned.

  • 01. “The initial set contains twelve outputs.” — SUPPORTED.
  • 02. “Four outputs were initially incorrect.” — SUPPORTED.
  • 03. “Eight outputs were initially correct.” — SUPPORTED.
  • 04. “The first revision fixes three of the original errors.” — SUPPORTED.
  • 05. “The first revision introduces no new error.” — CONTRADICTED: A7 regresses.
  • 06. “Two errors remain after the first revision.” — SUPPORTED.
  • 07. “Every output is correct after the first revision.” — CONTRADICTED.
  • 08. “All eight originally correct outputs remain correct after the first revision.” — CONTRADICTED: A7 changes.
  • 09. “The first revision reduces total errors from four to two.” — SUPPORTED.
  • 10. “A12 remains wrong after the first revision.” — SUPPORTED.
  • 11. “A7 becomes wrong after previously being correct.” — SUPPORTED.
  • 12. “The final inspected packet has twelve correct outputs.” — SUPPORTED.
  • 13. “The underlying language model was retrained as part of these edits.” — CONTRADICTED by the defined editing-only process.
  • 14. “The first attempt to repair errors caused no regression.” — CONTRADICTED.
  • 15. “The revised assistant will be correct on every unseen science question.” — NOT ESTABLISHED.
  • 16. “The exact financial cost of the review process is known.” — NOT ESTABLISHED.

22. Verify the test labels

Supported claims are 01, 02, 03, 04, 06, 09, 10, 11 and 12: nine. Contradicted claims are 05, 07, 08, 13 and 14: five. Not-established claims are 15 and 16: two. Nine plus five plus two equals sixteen.

An assistant that classifies the claim about retraining as supported simply because corrected text now appears is confusing output editing with a model-learning event. A report should say which technical component changed, and which claims remain untested.

23. The difference between a bug fix and a new capability

Correcting A2 may remove one known defect. It does not automatically add the ability to solve every question of the same type. A new capability claim needs testing on previously unseen examples representing the broader task.

A product team can maintain two evaluations: regression tests to ensure old errors stay fixed, and independent holdout tests to check whether performance transfers beyond those known cases. Both are useful, and neither replaces the other.

24. Model training is a separate process

Training or fine-tuning ordinarily involves a procedure that updates model parameters using data and an optimisation method. A single conversational correction does not, by itself, establish that such a procedure occurred. Some products may store preferences or use memory, but that is a distinct implementation detail.

Therefore the phrase “the AI learned from my correction” should be interpreted carefully. The current output may have improved; the product may have retained a note; or a future training process might incorporate certain feedback under applicable controls. Those are different claims.

25. Correction quality matters more than correction volume

Ten edits are not necessarily more useful than one carefully verified repair. An assistant could rewrite a paragraph repeatedly and introduce new mistakes on every pass. A good workflow measures which errors were closed, which remain open and which new errors appeared.

The relevant question is not “How many times did the assistant try?” but “Which claims now pass independent checks, and what changed in the process?”

26. Repair rate and drift

A practical improvement programme monitors the rate at which verified errors are repaired and the rate at which new errors or regressions appear. If new problems arrive faster than they can be corrected, the backlog can grow even when the team works continuously.

This can be expressed as a planning goal such as RepairRate ≥ DriftRate for a defined error queue and time period. It is an operational control idea, not a universal law of intelligent systems. The application must define how errors and rates are counted and whether all errors have equal consequence.

27. Monitoring after deployment

In March 2026, the US National Institute of Standards and Technology published AI 800-4 on challenges to monitoring deployed AI systems. Its discussion includes human–AI feedback loops, performance degradation, drift and the difficulties of post-deployment monitoring.

The report does not validate this fictional school example or claim that every system can learn safely from every correction. It supports the broader point that checking behaviour after deployment remains important and methodologically challenging.

28. Why the new answer needs verification

Suppose a model rewrites a factually incorrect sentence using a more precise technical word. The new wording may sound impressive and still be wrong. Verification should return to the authoritative source and confirm that the revised claim is supported.

This protects against a common failure: rewarding stylistic fluency rather than factual improvement. A polished answer is valuable only when the meaning and evidence remain correct.

29. How to handle a correction dispute

Two reviewers may disagree about whether a statement is wrong. The system should retain the competing explanations, consult the relevant primary source and use an agreed adjudication method. It should not choose the explanation written by the more forceful reviewer.

When the underlying facts are genuinely unsettled, the final output may need to preserve uncertainty rather than force a definitive correction. A feedback loop can end in a clear open issue when the evidence does not support a final answer.

30. A classroom practice activity

Give pupils a worksheet with twelve answer explanations. Four contain mistakes, but their positions are not revealed. Ask pupils to identify each error, explain it using a source, revise the wording and check every answer again.

Then deliberately introduce a regression in an originally correct answer. This helps pupils understand that improvement is not only repairing known mistakes. It also involves making sure the rest of the work remains correct after the edit.

31. An AI-builder’s checklist

Record each observed error with a unique identifier, source evidence, severity, affected outputs and proposed repair. Review the change, test the known error, run regressions, inspect independent examples and keep a clear release status.

Do not report success until the responsible system confirms the change. If a publication tool fails or returns an uncertain result, preserve that uncertainty instead of claiming the article is live. Tool receipts and checked state matter as much as the generated answer.

32. A transfer exercise about vocabulary

An AI says “school originally meant a place of compulsory examinations.” A reviewer supplies evidence about the Greek word scholē and its historical development. The assistant revises the explanation. What has been established? The revised passage can be checked for historical accuracy; a complete model retraining has not been established.

Now suppose a related article still repeats the old claim. The system needs a change-impact search and a separate correction. One fixed paragraph is not proof that every connected article has been repaired.

33. A transfer exercise about calculations

An assistant calculates a class average with the wrong denominator. A reviewer identifies that three pupils were absent. The assistant recomputes the average over the correct measured group. The arithmetic check may now pass, but the article also needs to state the denominator and what missing values mean.

This illustrates why a repair must address the mechanism, not merely replace one number. A new number without the right label can preserve the original misunderstanding.

34. What an honest improvement report looks like

A defensible report for our invented fixture reads: “Twelve outputs were checked. Four initially failed. The first repair fixed three but introduced one regression, leaving two failures. A subsequent verified repair closed both. The final twelve-item packet passes its reference checks. Generalisation to unseen tasks was not tested.”

That report is less dramatic than “the AI learned to be perfect”, but it tells the reader what happened, how it was measured and what remains unknown. It distinguishes a completed local correction from a universal capability claim.

Frequently asked questions

Does correcting a ChatGPT answer retrain the model? Not necessarily. Editing a response, storing a preference and changing model parameters are distinct processes.

What is a feedback loop? Observing a result, comparing it with a target, adjusting the system and checking the new result.

What is a regression? A previously correct outcome becoming wrong after a change.

Can a revised answer introduce new mistakes? Yes. That is why unrelated correct cases should also be checked.

Does 12/12 on a known test prove perfection? No. It shows performance on that specified test, not every unseen situation.

What is drift? A change in system behaviour or conditions that can undermine past assumptions or performance.

What evidence supports a reported successful correction? A clear reference, the recorded edit, independent verification and a confirmed saved or executed result.

The central lesson

A useful AI system improves through a disciplined cycle: detect an error, identify its source, make a controlled correction, check the repaired case and confirm that previously correct material still works. The strongest signal is verified net improvement, not a larger number of edits or a more enthusiastic apology.

Keeping response edits, workflow changes and model training separate makes feedback easier to understand. The goal is not to pretend an AI has learned everything from one correction. It is to build a process in which errors become visible, repairs are testable and claims of completion are supported by evidence.

Connected learning and trustworthy references