Detect stale or misleading context

2099. Lesson identity

Module

5.4 — Context management

Lesson

Detect stale or misleading context

Title

Detect stale or misleading context

Academic type

Debugging Lab

Schema type

Practical

Order

2 in the module

Content time

15–20 minutes

Practice time

15–20 minutes

Estimated time

30–40 minutes

2100. Learning objective

After this lesson, the learner can mark conflicts and uncertainty in a context packet and define a resolution action before an agent uses the packet to make a change.

2101. Why this matters

An agent can produce a coherent answer from context that is no longer true. A stale design note, an obsolete function name, or two contradictory constraints can make a technically plausible change wrong for the current game. Context selection is therefore not finished when files are gathered. You must also inspect the reliability of the evidence and make unresolved uncertainty visible.

2102. Prior knowledge

You should be able to select context by responsibility rather than proximity, as practiced in Select context by responsibility, not proximity. You should also be able to identify the owner of a behavior, its direct dependencies, and the constraints that govern it.

2103. Core concept

Context freshness is a decision property, not merely a timestamp.

A recent file can still be misleading if it describes the wrong responsibility. An old document can still be authoritative if it defines an unchanged contract. Evaluate each context item for:

• Source: Where did this claim come from?
• Scope: Which behavior or decision does it govern?
• Freshness: Is it likely to describe the current state?
• Authority: Does this source own or define the relevant decision?
• Confidence: How strongly does the available evidence support the claim?
• Consistency: Does it agree with the other evidence?
• Uncertainty: What remains unverified?

Keep freshness, authority, and confidence separate. A source can be current but outside its authority, or old but still authoritative for an unchanged contract. Derive a reliance action—use, verify, replace, or stop—from those fields rather than collapsing them into one reliability label.

When evidence conflicts, do not silently choose the more convenient version. Mark the conflict, state its impact, and define how it will be resolved.

2104. Mental model

Use the FRESHNESS–AUTHORITY–CONFIDENCE–CONFLICT–ACTION check for every high-impact context item:

Record the dimensions separately. For example:

Context item: interaction contract
Freshness: uncertain — the design note predates recent input changes
Authority: uncertain — the note describes intent, but the active owner is not identified
Confidence: low — the note and current input evidence support different timings
Conflict: design note says hold-to-use; active input evidence appears to define press-to-use
Impact: agent could implement the wrong interaction timing
Verification: inspect the active binding, owning interaction code, and relevant change history
Reliance action: stop until resolved

A context packet is trustworthy only when its unresolved uncertainty and resulting reliance limits are visible to the next decision-maker.

2105. Concrete example

Suppose an agent is asked to adjust a door interaction. The packet contains three items:

1. A design note stating that the player must hold the interaction button.
2. An input configuration showing an interaction action, but not its activation mode.
3. A recent interaction component whose comments refer to a one-press action.

The correct response is not to select the recent component automatically. The evidence has different roles and contains a conflict. Mark the packet as follows:

Conflict: interaction timing is inconsistent across the design note and code comment
Likely impact: changing feedback or input handling could preserve the wrong contract
Missing evidence: active action configuration and the authoritative interaction rule
Resolution owner: inspect the input binding and interaction component together
Agent instruction: do not implement timing changes until the conflict is resolved

This does not claim that the design note or the code comment is correct. It creates a controlled next step instead of hiding the uncertainty inside a prompt.

2106. AI-native workflow

Use the agent as a contradiction detector, not as the final authority:

1. Give the agent the selected context packet and ask it to list claims, sources, conflicts, and missing evidence.
2. Ask it to separate direct observations from interpretations.
3. Compare its conflict list with the actual packet. Add any conflict it missed.
4. Require a resolution action for every conflict that could change the requested behavior.
5. Only after conflicts are resolved should you ask the agent for an implementation plan.

A useful instruction is:

Audit this context packet before proposing a change. For each important claim, identify its source, scope, freshness, authority, and confidence as separate fields. List contradictions and missing evidence. Do not reconcile conflicts by guessing. For each blocking conflict, propose the smallest verification step, assign a reliance action of use, verify, replace, or stop, and state whether implementation should pause.

The agent may organize the audit, but you remain responsible for deciding whether the evidence is sufficient.

Before treating a repository artifact as current, ground the audit in Git evidence:

1. Run git status --short to identify uncommitted, staged, or untracked context. Do not assume the working-tree version is the accepted version.
2. Inspect the relevant git diff or git diff --staged to see exactly how the artifact differs from the recorded baseline.
3. Use git log -- <path> and inspect relevant commits to learn why and when the behavior changed.
4. Use git blame only when line-level history would help locate a change or its owning commit.
5. Compare those signals with the active configuration, implementation owner, and documented contract before assigning authority or a reliance action.

Commit timestamps, history, diffs, and blame are evidence signals, not automatic proof of authority. A recent commit can still concern the wrong scope, and an uncommitted working-tree change can be newer without being accepted.

2107. Common mistake

The common mistake is treating the newest-looking source as automatically authoritative. Recency is evidence, not ownership. Another mistake is recording only the preferred interpretation and deleting the disagreement. That makes the packet appear clearer while making the agent less reliable.

2108. Guided practice

Audit this supplied exercise packet. The requested change is: adjust the terminal interaction prompt without changing the activation behavior.

Packet artifacts

A. Working-tree implementation — TerminalInteractor.gd

const HOLD_SECONDS := 0.6

func _process(delta):
    if Input.is_action_pressed("interact"):
        held_time += delta
        if held_time >= HOLD_SECONDS:
            activate_terminal()

B. Active configuration — terminal_profile.cfg

interaction_action="interact"
interaction_mode="tap"
prompt_text="Access terminal"

C. Design note — docs/terminal_interaction.md

Last reviewed: 2024-02-10
Terminal access requires a 0.6-second hold to prevent accidental activation.
Owner: interaction design

D. Current unstaged diff

- if Input.is_action_just_pressed("interact"):
-     activate_terminal()
+ if Input.is_action_pressed("interact"):
+     held_time += delta
+     if held_time >= HOLD_SECONDS:
+         activate_terminal()

E. Relevant commit excerpt

commit 8c41e2a — 2024-05-18
Switch terminal interaction to a single press and align the active terminal profile.
Paths: TerminalInteractor.gd, terminal_profile.cfg

F. Working-tree status

 M TerminalInteractor.gd

Perform the audit without assuming that any artifact is correct merely because it is newer or appears in the working tree:

1. Extract each behavior claim and record its source and scope.
2. Assign separate freshness, authority, and confidence fields to every claim, with a reason for each judgment.
3. Identify contradictions, ambiguities, and missing evidence without being told which artifact should win.
4. State the likely impact of each conflict on the requested prompt change.
5. Choose the smallest repository or ownership check that could resolve each material conflict.
6. Assign each claim or conflict a reliance action: use, verify, replace, or stop.
7. Issue one final decision: proceed, proceed with limits, or stop pending verification. State what an agent may and may not assume.

Optional transfer practice: after completing the supplied packet, create a different packet from your own repository and apply the same audit fields and decision rule.

2109. Validation / evidence

The quiz remains a knowledge check. Demonstrate the capability independently by submitting the completed audit of the supplied packet.

Score the practical audit out of 10 points:

• 2 points — Source and scope: identifies the source and governed behavior for each material claim.
• 2 points — Reliability reasoning: evaluates freshness, authority, and confidence separately and supports each judgment with packet evidence.
• 2 points — Conflict analysis: marks material contradictions or missing evidence and explains their impact on the requested change.
• 2 points — Verification action: selects the smallest relevant repository or ownership check instead of guessing which source is correct.
• 2 points — Readiness decision: issues a justified proceed, proceed-with-limits, or stop decision and states what the agent may rely on.

A complete audit earns at least 8 points and may not omit the readiness decision or leave a material conflict silently reconciled. A reviewer should be able to identify what the agent is allowed to rely on without reconstructing your assumptions.

2110. Key takeaways

• Freshness, authority, and confidence answer different questions and must be recorded separately.
• Git status, diffs, history, timestamps, and blame provide evidence; none proves authority by itself.
• Contradictions must be marked instead of silently resolved.
• Uncertainty becomes useful when it includes impact, a reliance action, and the smallest next verification step.
• An agent can audit a context packet, but the learner decides whether to proceed, proceed with limits, or stop.

2111. Next lesson

Next, continue with 5.5 — Change safety, where you will apply controlled safeguards before an agent proposes or performs a change.

2112. Knowledge check