# 07. Failure Diagnosis

A poor result does not always need a longer prompt. Sometimes it needs one quiet minute to name what changed. That is still creative work—only here, creativity starts with observation rather than panic.

In this lesson, a **prompt** is a text instruction, a **reference** is a file that anchors a required property, and a **route** is an available way to run a generation in the chosen tool. Your job is to notice one specific failure, locate its likely layer, and run one clear repeat test.

```learner-callout
{"stable_id":"c080-observation-visible-not-vague","role":"observation","title":"Observation, not a verdict","body":"“Bad” cannot be tested. “The face changed after the turn,” “the text became unreadable,” or “the camera moved to the other side” are observations you can work with."}
```

## 1. First, record what actually broke

A result is broken when a property that had to stay consistent or change in a defined way behaves differently. Do not try to name the culprit yet. Separate the fact from the guess first.

For example, a robot picks up a cup. The cup may look beautiful while the robot becomes a different toy after the movement. The thing to test is not “the whole scene”; it is whether the robot’s form survives that action.

```learner-callout
{"stable_id":"c080-key-point-one-visible-failure","role":"key-point","title":"Key point","body":"One test begins with one main visible failure. If you cannot name it in one sentence, you do not yet know what you are changing."}
```

## 2. Find the nearest cause layer

The same symptom can come from different places. Look for the nearest layer that could have produced it instead of rewriting the entire project.

| What you see | Check first | First small test |
| --- | --- | --- |
| A face, object shape, or state does not hold | Reference: does the required property have a clear, non-conflicting anchor? | Keep one strong anchor for that property and leave the action unchanged |
| The main action is unclear or requirements fight each other | Prompt: can you see one action and one priority? | Simplify only the action or remove one conflict |
| An expected function is absent or behaves differently on screen | Route or interface | Compare the current official documentation with the real screen; a course diagram does not promise a service feature |
| Camera, axis, eyeline, or shot connection breaks | Camera and geometry | Keep one angle or one camera move |
| Movement becomes unreadable | Movement and timing | Keep one action, its start, and its end |
| The needed element exists but the join, rhythm, or exact graphic is weak | Editing | Separate generation from the edit and check one join or graphic layer |

```learner-callout
{"stable_id":"c080-caution-interface-not-promise","role":"caution","title":"Caution","body":"If an expected function is absent on screen, do not invent a workaround from memory. Check current documentation and the actual interface first; this lesson does not claim a particular service’s availability or behaviour."}
```

## 3. Run one clean test

Imagine a teaching scenario: the character is recognisable in the first result, but their face changes during a quick turn. That is an observation. One possible hypothesis is that the identity anchor is too weak for such a complex movement. It is not proof yet; it is a reason for one test.

For the next attempt, keep the scene, angle, lighting, and action. Change only the identity anchor to one clearer reference. Then compare the two results against one criterion: is the face recognisable before and after the turn? If yes, accept the test as a useful observation. If not, reject the hypothesis or schedule the next test—without mixing it with five new changes.

```learner-callout
{"stable_id":"c080-technique-one-variable","role":"technique","title":"Technique: one variable","body":"Keep the accepted foundation and change only one meaningful thing. Then the difference between two results becomes evidence for the next decision instead of another mystery."}
```

Complete this record before the repeat test. This is the only block you need to copy.

```template
Expected:
Received:
One main visible failure:
Likely cause layer: reference / prompt / route or interface / camera and geometry / movement and timing / editing
Hypothesis:
Change only this in the next test:
Do not change:
Compare using this criterion:
Decision after comparison: accept / reject / schedule one next test
```

Do not turn the record into a long list of prohibitions. Its job is to make the cause testable. If the new text doubles in length and the number of variables grows, diagnosis has turned back into panic.

---

## 4. When to change the control method, not the wording

If the same failure repeats three times, stop endlessly adjusting the same words. The weak point may be the current control method, not one particular attempt.

Choose one new route: prepare a more precise reference, split the action into segments, lock a start or final frame, simplify the angle, or move the exact element into editing. Do not do all of them at once. A new strategy also begins with one observable test.

## 5. Practice and acceptance point

Choose one existing failed result. The exercise does not require a generation: you can prepare the record and criterion before the next run.

```learner-callout
{"stable_id":"c080-practice-bounded-retry","role":"practice","title":"Practice","body":"Describe one visible failure, complete the record, and schedule one test with one variable. Until comparison, do not change the reference, movement, lighting, camera, and route all at once."}
```

Once you have two comparable results, make only one of three decisions: the criterion is met—keep the change; the criterion is not met—reject the hypothesis; the difference is unreadable—repeat the test with a clearer criterion. Do not call a result repaired until you can show what became better.

```learner-callout
{"stable_id":"c080-checkpoint-visible-decision","role":"checkpoint","title":"Checkpoint","body":"The lesson is complete when you have an original and repeat result, one described failure, one changed variable, a visible comparison criterion, and an honest decision: accept, reject, or schedule the next test."}
```

Next: once the failure is corrected or honestly bounded, move to selecting a version and final assembly.