← AI Fundamentals
0/15 complete

Module 02 · Mastering Context Threads

Detect and Correct Instruction Drift

20 minfocused lesson1copyable prompts3self-checks0source links
Open lesson + course map

On this lesson

Course outline

“Instruction drift” is a useful label for an observable problem: a response no longer follows a rule you set earlier. The label does not prove the cause. Long context, conflicting instructions, product behaviour, tool output, model variability, or an unclear rule may all contribute. Your job is to detect the failed requirement and restore a checked working state.

// concept

Observe the Violation, Not a Story About It

Examples:

  • Requirement: under 100 words. Output: 220 words.
  • Requirement: table with four columns. Output: prose paragraphs.
  • Requirement: use only supplied facts. Output: adds an unsourced claim.
  • Requirement: formal Urdu. Output: switches to casual Roman Urdu.
  • Requirement: return valid JSON. Output: includes commentary outside the object.

These are measurable failures. “The model forgot” is only an inference and does not tell you whether a correction worked.

// concept

The Correction Loop

  1. Quote the failed requirement. Use the exact accepted wording.
  2. Show the evidence. Point to the part of the output that violates it.
  3. Request a corrected output. Ask for the whole affected section, not a promise about future behaviour.
  4. Validate independently. Count words, parse JSON, compare facts, or use the human checklist.
  5. Escalate if it fails again. Simplify the task, remove conflicting context, start a fresh thread with a verified handoff, or use a manual process.
// template — copy me7 lines
The last response did not meet this requirement:
“Return a table with columns Source / Claim / Confidence / Next check.”

Evidence: the response is three paragraphs and includes no source field.

Regenerate the answer as the four-column table. Use only the supplied text.
Write “source missing” instead of guessing. I will validate the table after it is returned.

Do not ask the model to “confirm it will remember.” A confirmation is not evidence; the corrected output is.

// concept

Build a Requirement Checklist

Before a long task, list the requirements that matter:

RequirementValidation method
Length limitWord or character count
Required fieldsChecklist or schema validation
Forbidden inventionCompare every claim with approved sources
Language and toneHuman reviewer with relevant fluency
JSON or codeParser, formatter, test, or compiler
Privacy boundaryConfirm no restricted data appears in input or output

Check at meaningful milestones: after a section, before a handoff, and before delivery. A fixed “every 15 messages” rule has no universal basis.

// concept

Prevent Avoidable Conflicts

  • Put critical requirements close to the task and make them observable.
  • Resolve conflicts such as “be detailed” and “under 50 words” before running.
  • Separate facts, style preferences, and output schema.
  • Use saved instructions only when the feature is available and approved; re-check them in the task.
  • Carry a dated, verified summary into a new thread when old context creates confusion.
  • Keep source material and final acceptance outside the chat so you can recover.

“Always” and “never” can clarify a true hard boundary, but those words do not make a model more reliable by themselves. Pair the boundary with a validation step.

// concept

Know When to Stop Correcting

Do not keep prompting indefinitely. Move to a safer alternative when:

  • the same material requirement fails after a clear retry;
  • a source-sensitive answer keeps inventing claims;
  • the context contains private data that should not be there;
  • a deterministic tool such as a parser, spreadsheet formula, or test is more appropriate; or
  • the deadline requires a human-written answer.

Starting a new thread can help, but it can also discard useful context. Use the verified handoff from Lesson 2.2 and re-check all facts.

// pakistan_angle

Pakistan Angle

For a bilingual newsletter, WhatsApp support script, or client edit, include separate checks for Urdu script, Roman-Urdu spelling, English terms, names, dates, and rupee amounts. Language ratio is not a substitute for fluency. Ask an appropriate reviewer to check sensitive or public-facing wording.

If connectivity or power is unstable, store the requirement list and accepted draft locally. Do not rely on a chat tab as the only record. A correction workflow can reduce errors, but it does not guarantee a client review, rating, or repeat contract.

// concept

Do This Now — Module 2 Integration

Use one non-sensitive task:

  1. Open a scoped thread and add three verified facts.
  2. Set one format requirement and one evidence requirement.
  3. Produce a short draft.
  4. Validate it. If a requirement failed, run the correction loop.
  5. Save the before, after, and validation result.
  6. Generate the Lesson 2.2 handoff, correct it manually, and test it in a fresh thread.

You do not need to manufacture drift or run a fixed number of exchanges. The deliverable is a documented requirement, a validation method, and—if needed—a corrected output.

Self-check

Before you mark Lesson 2.3 complete

  • Can I explain “Detect and Correct Instruction Drift” without reading the lesson back word for word?
  • Did I complete the lesson’s practice step on a real or clearly labelled sample task?
  • Did I check the result for invented facts, private data, unsafe actions, and mismatch with the brief?