THE CORE AIM OF VOCABULARY MASTERY · AI AGENT CORRECTIVE ACTION TRACKING · ASSIGN → IMPLEMENT → VERIFY → CLOSE → LEARN
AI agent corrective action tracking vocabulary explains what happens after a reliability or educational-content problem has been investigated. A post-incident review might identify a missing source check, a misleading publishing status, or inadequate permissions. But discovering a weakness and fixing it are different events. Words such as corrective action, preventive action, action owner, due date, acceptance criterion, verification, effectiveness check, residual risk, closure and recurrence help turn lessons into observable improvements.
The core aim of vocabulary mastery for AI agent corrective action tracking is to distinguish a promise to fix something from evidence that it was fixed. A learner should be able to name the failure, state the specific change required, assign responsibility, define how success will be checked and explain what remains unresolved. The goal is neither to create an endless paperwork process nor to close a ticket because someone typed ‘done’.
This article belongs to the eduKateSG Vocabulary Hub and extends AI Agent Post-Incident Review Vocabulary. A postmortem reconstructs what happened and identifies possible improvements; this guide owns the lifecycle of those improvements from agreement to independently checked effectiveness. It also connects to AI Agent Regression Testing Vocabulary and AI Agent Dependency Mapping Vocabulary.
Central proposition: A corrective action is not complete merely when a change is written, assigned, merged or deployed. Completion requires the agreed evidence that the relevant defect has been addressed, including the user-facing behaviour where appropriate.
The 60-second corrective-action router
- Capture the problem: link the action to a specific incident, finding or near miss
- Define the mechanism: identify the missing control, incorrect source, broken dependency or misleading workflow
- Assign one accountable owner: name collaborators separately rather than assigning the action vaguely to everyone
- Specify acceptance criteria: state what must be observable for the action to pass
- Implement and test: perform the change and check the intended behaviour
- Verify effectiveness: determine whether the failure route is actually reduced or blocked
- Close with a receipt: record evidence, reviewer and remaining risks, then watch for recurrence
Essential vocabulary: what an action tracker must distinguish
| Term | Meaning in plain English | Review question |
|---|---|---|
| Corrective action | A change intended to address an observed failure or nonconformity. | What revealed defect will be corrected? |
| Preventive action | A change intended to reduce a plausible future failure. | Which weakness is being addressed before harm? |
| Action item | A discrete piece of agreed follow-up work. | What exactly will someone do? |
| CAPA | Corrective and preventive action as a structured improvement practice. | How will causes and recurrence be addressed? |
| Owner | The person or role accountable for completion. | Who ensures that it happens? |
| Collaborator | A person supporting an action without replacing its owner. | Who contributes specialist work? |
| Due date | The expected completion date or milestone. | When should progress be reviewed? |
| Priority | The relative urgency and importance of the action. | What should be addressed first? |
| Severity | The potential or realised consequences of the underlying issue. | How serious was the failure? |
| Acceptance criterion | A measurable pass condition for the action. | What proof counts as completion? |
| Implementation status | Whether the planned change has been made. | Has the code, content or process changed? |
| Verification | Checking that the implemented change meets the agreed condition. | Does the fix behave as specified? |
| Effectiveness check | Evaluating whether the change actually reduces recurrence or impact. | Did it solve the important problem? |
| Regression test | A repeatable check that important behaviour remains acceptable. | Will this failure be detected next time? |
| Dependency | Another component or decision required before an action can finish. | What could block completion? |
| Evidence link | An identifiable reference to test, record or reviewed artefact. | Can another reviewer repeat the check? |
| Residual risk | Unresolved uncertainty or exposure after the action. | What remains possible? |
| Mitigation | An immediate reduction of impact that may precede a permanent repair. | Are users protected while the fix is prepared? |
| Closure | A reviewed decision that the item has met its defined exit condition. | Why may this item be closed? |
| Recurrence | Another occurrence of a related failure after action was taken. | Was the change durable? |
| Action backlog | The organised set of open improvement items. | Which follow-ups remain outstanding? |
Corrective action versus preventive action: the difference matters
Corrective action follows an observed defect
Suppose a published Primary 6 Science worksheet describes evaporation as a change from gas to liquid. The organisation corrects the content and identifies why the editorial process failed to detect the inversion. Adding a subject-specific review for phase-change statements is a corrective action tied to an observed mistake.
Preventive action addresses a plausible pathway
Suppose no privacy breach has occurred, but a review finds that the assistant can request more student records than its assigned task requires. Restricting the scope and adding resource-level negative tests are preventive measures. The same action may have both corrective and preventive effects, but the record should explain which existing problem and future risk it addresses.
Google SRE’s discussion of lessons learned connects blameless incident review to corrective and preventive action: the point is to investigate the conditions of failure and improve the system. That does not mean every incident requires the same form or ticket workflow. The level of process should fit its consequences.
A worked example: the vocabulary article that was not actually published
An article-writing assistant creates a draft in WordPress, but its final chat message reports ‘published successfully’. The editor clicks the predicted public URL and cannot open the article. Initial triage reveals that the post-creation tool returned status draft. The assistant’s publishing-status interpretation was wrong.
The immediate correction is to tell the editor the actual draft status and give the authorised edit link. The preventive follow-up is to stop future responses from claiming publication without a returned published status and stable post identifier. A targeted action item can name the exact validator, provide a test case for draft and publish responses, and require proof from a new controlled run.
| Stage | Example | What it establishes |
|---|---|---|
| Finding | Assistant incorrectly reported a WordPress draft as public. | Specific observed defect. |
| Containment | Correct the message and prevent reuse of the invented public link. | Limits immediate misinformation. |
| Action | Add status-aware final-response validation. | Describes the changed control. |
| Owner | Publishing integration owner. | Creates accountability. |
| Test | Draft must be labelled draft; publish must return an actual live URL. | Defines acceptance. |
| Evidence | Tool result, test run and retrieved post state. | Makes verification repeatable. |
| Effectiveness | A controlled batch no longer reports unconfirmed writes as public. | Checks behaviour in use. |
| Closure | Reviewer confirms the specified tests and deployment. | Completes the agreed action. |
A promised fix is not proof: the five different statuses
| Status | What it means | What it does not prove |
|---|---|---|
| Proposed | A possible action has been described. | That anyone has agreed to do it. |
| Assigned | An accountable owner has accepted the task. | That the solution is correct. |
| Implemented | The described change exists in code, process or content. | That it works in the intended environment. |
| Verified | Agreed evidence shows the stated acceptance conditions were met. | That every related future defect is impossible. |
| Closed | A responsible reviewer accepted completion and residual limitations. | That all neighbouring dependencies are risk-free. |
Some teams add statuses such as blocked, in review, deferred or cancelled. These are useful when they represent real states rather than merely a long dropdown menu. A deferred high-priority action should remain visible to decision-makers, and cancellation should record why the original problem no longer requires that particular remedy.
The acceptance criterion is the heart of the task
A weak action says ‘improve fact-checking’. A stronger action says ‘When an agent makes a claim about a current SEAB examination code, require an applicable source edition and a passage-level support check before the content is labelled verified’. This is testable because the reviewer can present a stale edition and observe that the validator does not accept it as current.
A still stronger action names the intended integration point and output evidence. For example: the controlled test suite includes one correct-year and one superseded-year case; both pass under the actual source-checking workflow; the review record identifies the source versions; and the published correction is read back from WordPress. Evidence should match the failure, not merely look impressive.
Why one owner is better than seven vague names
A failure may involve technical operations, an English tutor, a science reviewer and a site editor. Multiple people can contribute, but the tracker should identify who is responsible for deciding that the action has actually met its criteria. ‘Everyone’ is not a reliable owner: a task without a clear point of contact can become permanently pending while each participant assumes someone else is handling it.
Google’s postmortem culture materials describe how clearly owned, measurable action items are more likely to be completed. The owner need not personally perform every step, but should track dependencies, communicate blockers and ensure that verification is available.
The action record: a small structure that survives handoffs
| Field | Example | Why the field matters |
|---|---|---|
| Action ID | EDK-AGENT-CA-014 | Distinguishes one commitment from another. |
| Origin | Incorrect publication status incident | Connects action to evidence. |
| Finding | Draft reported as published | States the failure without blame. |
| Owner | Publishing tool maintainer | Establishes responsibility. |
| Priority | Based on operational and reader impact | Supports triage. |
| Target component | Final-response status validator | Locates the change. |
| Acceptance criteria | Draft/publish/failure status test cases pass | Defines completion. |
| Evidence | Test run ID and saved post verification | Permits independent review. |
| Dependencies | WordPress integration and test environment | Explains blockers. |
| Residual risk | Unexpected external status values still need handling | Preserves uncertainty. |
| Closure reviewer | Authorised editor or reliability reviewer | Records the final decision. |
Testing the repair without changing the user’s live content
A publishing-status test can use a designated staging article or a controlled fake response rather than posting duplicate pages to the live education site. A source-verification test can use curated passages that include old and current editions. A private-record access test should use appropriate test identities and non-sensitive data. The testing method is part of the action’s safety.
This is why deterministic unit checks and end-to-end tests complement each other. A parser can correctly read status: publish in isolation while a complete workflow still ignores content warnings. A successful unit test shows one component works; a verified user-facing result demonstrates that the integrated path meets its chosen condition.
Effectiveness checks: did the problem become less likely?
An action may pass a narrow acceptance test and still fail to reduce recurrence in production. A new source-version validator might be deployed, but an older publishing route could bypass it. An effectiveness check looks beyond the existence of the changed code: does the relevant workflow now use the control, and do monitoring or representative test cases show the intended improvement?
Effectiveness cannot always be proved by the absence of incidents during a short period. Rare failures may simply not recur. Better evidence combines a repeatable test of the failure route, confirmation that the control is applied in the intended environment and ongoing monitoring proportionate to the risk.
Blocked, overdue and superseded actions
A task may be blocked by an unavailable connector, an unresolved source rights question or a required reviewer. The owner should record the dependency rather than mark completion. If a newer platform design makes the proposed fix obsolete, the team can close or replace the task with an explicit reason and evidence that the original risk is handled elsewhere.
Overdue actions should prompt risk-informed prioritisation, not automatic blame. A high-impact unaddressed permission issue may require an interim mitigation while a permanent repair is prepared. A minor formatting improvement may reasonably wait behind work needed to preserve educational correctness. The tracker should explain those decisions.
Measure the action programme without gaming it
A dashboard showing ninety-nine closed tickets can look strong even if the most important security fix remains open. Simple closure counts do not capture risk. Useful indicators include the age of high-priority items, proportion of corrective actions with verifiable evidence, repeat incidents involving the same pathway and whether temporary mitigations still need permanent resolution.
Do not optimise the number of closed tasks by writing tiny, low-value items while deferring the actual cause. The programme should reflect the quality of risk reduction and the experience of the learners, parents and operators who depend on it.
A corrective-action design exercise
- Scenario 1: A science worksheet has a wrong answer. Write separate immediate correction and recurrence-prevention actions.
- Scenario 2: A PDF parser loses the last column of an assessment table. Identify the tool test and the final rendered-artifact check.
- Scenario 3: An assistant is shown a private-record tool for a public syllabus question. Specify a narrower tool policy and test for inappropriate invocation.
- Scenario 4: A published article cites an obsolete official document. Define a claim-source version check rather than asking for a complete generic rewrite.
- Scenario 5: A fix is marked merged but has not been deployed. Explain why its verification and closure statuses remain open.
Common corrective-action mistakes
- ‘Be more careful’ as the only action: define a testable change to a system or process.
- Closing when code is merged: check the deployed and user-facing behaviour.
- Recording no owner: assign accountability and collaborators.
- Using only calendar deadlines: include acceptance criteria and actual risk.
- Treating all actions as equally important: prioritise by consequence and recurrence risk.
- Assuming a patch addresses every descendant: check dependent documents and tools.
- Leaving temporary mitigations forever: review whether permanent controls are still needed.
- Claiming no recurrence proves elimination: keep meaningful regression tests.
- Deleting evidence after closure: retain the relevant records according to applicable policy.
Frequently asked questions
What is AI agent corrective action tracking?
It is the organised process for assigning, implementing and verifying improvements arising from incidents, reviews or discovered weaknesses in AI-agent workflows.
Is a corrective action the same as an immediate mitigation?
Not necessarily. A mitigation reduces current harm; a corrective action addresses the identified problem or failure mechanism.
Why must an action have one owner?
A named accountable person or role can coordinate collaborators, resolve blockers and ensure completion evidence is reviewed.
What makes a corrective action measurable?
A specific change, defined pass criteria and evidence that another reviewer can inspect or reproduce.
Does a successful unit test prove effectiveness?
It proves a particular condition under test, but broader effectiveness may require integration checks and relevant observation after deployment.
Can a task be closed even if some risk remains?
Yes, when authorised closure criteria allow it and residual risk is explicitly documented, assigned and appropriately managed.
References and connected learning
- Google SRE Workbook — Postmortem Culture (action ownership and concrete follow-up).
- Google SRE — Incident Management Guide (tracking corrective actions after incident response).
- Google SRE — Lessons Learned (corrective and preventive action culture).
- AI Agent Post-Incident Review Vocabulary (finding contributing factors).
- AI Agent Regression Testing Vocabulary (repeatable verification).
- AI Agent Dependency Mapping Vocabulary (affected systems).
- AI Agent Artifact Management Vocabulary (versioned released outputs).
- Immutable eduKateSG learning reference (evidence-led teaching and diagnosis).
The corrective action tracking vocabulary standard
Mastery means the learner can turn one observed AI-agent problem into a specific owned action, distinguish implementation from verification, establish a meaningful effectiveness check, address residual risk and produce an accurate closure record. The core aim is not to accumulate postmortems or tick boxes. It is to make each meaningful finding a defensible improvement in the service learners actually use.