Lessons 42.1 and 42.2 gave the project a memory: a feature spec for each piece of work, and a small file set where each kind of truth has one canonical home. That solves orientation. It does not yet solve time.

Projects live for weeks and months. An API surprises you. A privacy question gets answered. An assumption quietly turns false. Each AI session implements what it believes is today's truth — and without change control, the file set becomes a museum of contradicting yesterdays.

This lesson keeps the knowledge honest after the first week.

The file set needs a contradiction preventer

Every contradiction you have seen in an AI-built project has the same shape. Someone decided something in chat. Nobody wrote it down. Two sessions later, a new agent cannot find it, so it decides again — differently — in code. Now the docs say one thing, the code does another, and nobody knows which is intended.

The prevention is a decision record: short, dated, and boring enough that people actually use it. Every meaningful choice gets seven fields:

• Date: when it was decided.
• Decision: what was chosen, in one sentence.
• Context: what problem forced the choice.
• Alternatives considered: what else was on the table.
• Why this choice: the reason, not just the winner.
• Consequences: what must now happen consistently.
• Owner and review trigger: who stands behind it, and what event should reopen it.

Example from the research dashboard:

Five lines. Any future agent reading it knows what to build and what not to invent.

Facts, assumptions, decisions, open questions

Most messy transcripts contain four kinds of statements tangled together. Separating them is the highest-value reading skill in this class:

The dangerous row is the open question. If an unresolved question hides inside a chat — "should watchlists be shareable?" — the next agent will usually answer it implicitly through code. It will add a share button, or a shared endpoint, or a database field that assumes sharing. A product decision with privacy consequences gets made by autocomplete.

The rule: an open question is a visible work item with an owner, never a gap for AI to fill. Label it in the spec, assign who answers it and by when, and instruct agents explicitly: do not implement around it until the owner decides.

Assumptions deserve the same honesty. "Most sources include a date" is fine as a starting belief — until you measure it. Label it as an assumption, check it against real responses, and promote it to a fact or replace it with a decision when the evidence arrives.

The plan-change protocol

When implementation reveals a true change — the provider really does omit dates, the auth rule really does block sharing — run this sequence before the next build task starts:

discovery → impact note → update the affected docs
  → review and approval → replace the old task with a new bounded task
  → record the decision → continue

In operational detail:

1. Discovery. The worker stops and states what it found, with evidence: sample responses, failing checks, exact behavior. 2. Impact note. What breaks or changes? Which files, contracts, UI states, roadmap phases are affected? One short paragraph. 3. Update the affected docs. Change PRD.md, ARCHITECTURE.md, API.md, or ROADMAP.md — whichever owns the truth — not just the code. Link, do not duplicate. 4. Review and approval. The human or system owner approves the new direction. High-risk changes (identity, access, money, data retention) always need explicit approval. 5. New bounded task. Replace the old task card with a new one that reflects the decision. Do not stretch the old task to cover contradictory work. 6. Record the decision. Add the DECISIONS.md entry with owner and reopen trigger. 7. Continue. Only now does implementation resume.

This is not bureaucracy. It is the mechanism that stops code from implementing yesterday's truth. A two-minute protocol now prevents a two-day contradiction cleanup later — and it is the same loop Part IX taught, applied to the document set.

A scenario: the dates are inconsistent

Walk through it with the dashboard. The task is "show publication dates beside citations." Mid-task, the agent discovers the provider omits publishedAt for roughly a third of sources.

The wrong response is to guess: derive dates from article text, silently drop dateless sources, or hard-code "recent." Each guess looks like progress and corrupts the product differently.

The right response divides labor the way this course always does. The model investigates options: how often is the field missing, can an approved field substitute, what would a second source cost, what do the UI states look like for each option. It reports evidence, not a verdict. The human — the system owner — records the decision: show "Date unavailable," mark the field nullable in API.md, require the missing-date UI state and test. A new bounded task replaces the old one. Work continues from a truth everyone shares.

Notice the pattern: AI explores, human decides, the file set remembers. That is change control in one sentence.

Exercise: record a decision and classify a transcript

Two parts, fifteen minutes.

First, write one real DECISIONS.md entry for your current project using all seven fields — date, decision, context, alternatives, why, consequences, owner and trigger — plus one open question with a named owner and a date for resolution.

Second, take any messy chat transcript (yours or an AI session's) and ask an AI: "Classify each statement as fact, assumption, decision, or open question. List the open questions separately. Do not invent answers to them." Check whether it found the guesses you already sensed were there.

Finish line: a decision record with a named owner and a clear consequence for the next task, plus a classified transcript with at least one owned open question.

Verify: confirm the consequence names the exact files or checks the next task must honor (for example, "API.md marks publishedAt nullable; UI test covers the missing-date state"). If the consequence is vague — "handle dates better" — rewrite it until a new session could act on it without asking you.

Common failure: recording the decision in chat and moving on. Recovery: if it is not in DECISIONS.md and linked from the affected spec, it did not happen. Paste it in now while the reason is fresh.

Check your understanding

1. What seven fields make a decision record usable? 2. Why is an unlabeled assumption dangerous in an AI-built project? 3. What must happen to an open question before implementation continues around it? 4. Recite the plan-change protocol in order. Where does approval sit? 5. In the provider-dates scenario, what does the model do and what does the human do?

---

Class 42 is complete. Git remembers what changed; your spec set now remembers what was supposed to be true, where each answer lives, and how each choice was made. Class 43 puts that durable intent to work — turning product requirements into a sequenced, risk-aware roadmap with interfaces planned before parallel workers build them.