WEBVTT

1
00:00:00.000 --> 00:00:03.970
This challenge asks you to rescue a
vague request using the three habits

2
00:00:04.017 --> 00:00:07.697
we have practiced. You will
identify what the evidence supports,

3
00:00:07.941 --> 00:00:11.691
supply useful context, and write
a bounded engineering brief.

4
00:00:11.970 --> 00:00:15.731
The result is a small evidence packet
that another person can inspect.

5
00:00:16.114 --> 00:00:19.446
You do not need physical hardware
or an uninterrupted AI account

6
00:00:19.621 --> 00:00:23.324
to complete the reasoning work.
Read the supplied request carefully.

7
00:00:23.533 --> 00:00:27.400
It says the sensor is unreliable,
asks you to make the readings accurate,

8
00:00:27.643 --> 00:00:30.546
permits any change, and demands
a statement that it works.

9
00:00:30.871 --> 00:00:35.190
The only evidence is an authored synthetic
log with validity flags and temperatures.

10
00:00:35.573 --> 00:00:39.416
The request has already jumped from
software input to a physical diagnosis.

11
00:00:39.741 --> 00:00:43.387
Our first task is to separate that
assumption from what we actually know.

12
00:00:43.712 --> 00:00:46.545
Open the Chapter 3
original reporting fixture.

13
00:00:46.928 --> 00:00:49.447
Identify its file name and
the meaning of its fields.

14
00:00:49.726 --> 00:00:52.338
Count the records and
locate any invalid sample.

15
00:00:52.721 --> 00:00:54.916
Record the input's origin as synthetic.

16
00:00:55.357 --> 00:00:58.619
A temperature number in this
file is a controlled value chosen

17
00:00:58.666 --> 00:01:02.207
for a software exercise. It is
not a measurement of the room,

18
00:01:02.381 --> 00:01:05.121
and it cannot establish
whether a sensor is calibrated.

19
00:01:05.562 --> 00:01:08.917
Now identify a problem the
available material can support.

20
00:01:09.300 --> 00:01:11.785
Perhaps the explanatory
report hides the validity

21
00:01:11.854 --> 00:01:14.931
flag or fails to identify
synthetic origin.

22
00:01:15.314 --> 00:01:18.367
Those are concrete reporting
problems. We can improve

23
00:01:18.391 --> 00:01:21.920
the explanation while preserving
the underlying numbers and policy.

24
00:01:22.245 --> 00:01:25.403
We do not need to replace hardware,
invent a communication fault,

25
00:01:25.438 --> 00:01:28.364
or change the warning threshold
to make the task useful.

26
00:01:29.061 --> 00:01:30.744
Write the goal in one sentence.

27
00:01:31.069 --> 00:01:34.749
For example, make the report clearly
distinguish valid and invalid

28
00:01:34.796 --> 00:01:38.569
synthetic records. Write the current
behavior in a separate sentence.

29
00:01:39.173 --> 00:01:42.099
This prevents the brief from
treating a broad accusation such

30
00:01:42.145 --> 00:01:45.651
as unreliable as if it were an
observed technical condition.

31
00:01:46.255 --> 00:01:50.377
Your revised task should be understandable
without the original emotional context

32
00:01:50.423 --> 00:01:52.327
of a frustrating debugging session.

33
00:01:52.710 --> 00:01:56.413
Name the Chapter Three resource
version and actual fixture.

34
00:01:56.797 --> 00:01:58.851
Include the relevant small input,

35
00:01:58.968 --> 00:02:02.021
or point to the file if the
selected interface can inspect it.

36
00:02:02.404 --> 00:02:05.609
Preserve the original. If you
shorten the input for discussion,

37
00:02:05.887 --> 00:02:09.080
state which records you selected
and whether any values changed.

38
00:02:09.777 --> 00:02:14.014
A reviewer should be able to return to the
source and check your interpretation. Set

39
00:02:14.061 --> 00:02:17.358
the boundaries. Preserve
temperatures, validity flags,

40
00:02:17.532 --> 00:02:20.562
state names, record order,
and existing policy.

41
00:02:21.514 --> 00:02:25.160
Do not edit firmware, dependencies,
timing, or the fixture.

42
00:02:25.601 --> 00:02:28.944
Request one artifact, such
as a proposed report format

43
00:02:29.002 --> 00:02:32.172
with two illustrative lines
and a short verification plan.

44
00:02:32.555 --> 00:02:35.678
This turns the task from an
open-ended rewrite into a decision

45
00:02:35.736 --> 00:02:40.148
you can review in one sitting. Define
acceptance before looking at the response.

46
00:02:40.473 --> 00:02:44.270
The report must identify synthetic
origin, retain invalid status,

47
00:02:44.421 --> 00:02:47.521
preserve original facts, and
avoid a physical accuracy claim.

48
00:02:47.799 --> 00:02:50.678
It must distinguish proposed
checks from executed results.

49
00:02:50.957 --> 00:02:53.929
Add a negative case so that
an invalid record containing

50
00:02:53.976 --> 00:02:57.180
a plausible number cannot pass
unnoticed as a valid reading.

51
00:02:57.621 --> 00:03:00.454
If you use a live assistant,
save the actual answer.

52
00:03:00.779 --> 00:03:02.718
If service access is unavailable,

53
00:03:03.043 --> 00:03:06.201
analyze the original challenge
response provided in the lesson.

54
00:03:06.898 --> 00:03:10.114
That response is deliberately
mixed: it proposes useful

55
00:03:10.172 --> 00:03:13.759
synthetic labels, suggests raising
the threshold to suppress warnings,

56
00:03:13.852 --> 00:03:15.814
and promises to report calibration.

57
00:03:16.418 --> 00:03:20.586
It was written for instruction, so do
not call it an observed model failure.

58
00:03:20.969 --> 00:03:22.826
Review each idea separately.

59
00:03:23.268 --> 00:03:27.494
The synthetic label serves the task and
may be accepted if it preserves the data.

60
00:03:28.005 --> 00:03:31.650
Raising the threshold changes policy
and lacks support from the brief.

61
00:03:31.975 --> 00:03:35.644
It might hide an inconvenient warning
without addressing the reporting problem.

62
00:03:36.085 --> 00:03:39.939
The calibration statement requires
physical evidence that we do not have.

63
00:03:40.450 --> 00:03:43.887
Reject those two proposals with
reasons tied to the task and evidence.

64
00:03:44.270 --> 00:03:47.834
A good review is actionable.
Instead of saying the answer is bad,

65
00:03:48.043 --> 00:03:51.677
say keep the origin label,
remove the threshold change,

66
00:03:51.828 --> 00:03:55.334
and replace the calibration claim
with an explicit limitation.

67
00:03:55.775 --> 00:03:59.641
Then name the next check: compare the
proposed report against the original

68
00:03:59.711 --> 00:04:03.054
records and confirm that validity
and values are preserved.

69
00:04:03.333 --> 00:04:06.340
This gives the author or assistant
a clear correction to make.

70
00:04:06.851 --> 00:04:09.684
Your evidence table should
contain at least five rows.

71
00:04:10.009 --> 00:04:13.643
Include a supported input fact, a
documented rule from the original note,

72
00:04:13.736 --> 00:04:16.987
an unresolved requirement if
one matters, a proposed action,

73
00:04:17.010 --> 00:04:21.189
and a physical claim that the input
cannot establish. The point is not to fill

74
00:04:21.247 --> 00:04:24.963
categories mechanically. It is to make
the current status of each consequential

75
00:04:25.009 --> 00:04:27.818
statement visible. Consider
what happens if the assistant

76
00:04:27.876 --> 00:04:29.537
answers correctly the first time.

77
00:04:30.233 --> 00:04:33.461
You still complete the review.
Identify why the result

78
00:04:33.519 --> 00:04:37.315
satisfies each criterion and
state what it does not establish.

79
00:04:37.919 --> 00:04:40.009
Success does not require
catching an error.

80
00:04:40.392 --> 00:04:43.747
It requires a method that would catch
a meaningful error if one appeared.

81
00:04:44.351 --> 00:04:48.194
The supplied mixed response lets everyone
practice that part of the method.

82
00:04:48.635 --> 00:04:52.605
Consider the opposite result: the
assistant ignores your constraints.

83
00:04:52.989 --> 00:04:57.539
Preserve the response and restart from
the unchanged input with a narrower task.

84
00:04:57.981 --> 00:05:01.498
You may ask for a plan before edits
if the boundary remains unclear.

85
00:05:01.940 --> 00:05:06.282
Do not keep escalating the wording while
allowing unrelated changes to accumulate.

86
00:05:06.607 --> 00:05:10.717
The recovery should leave a known baseline
and a smaller, more checkable request.

87
00:05:11.100 --> 00:05:14.734
Before submission, inspect the
packet as if you were another maker.

88
00:05:15.059 --> 00:05:17.950
Can you find the input? Can
you tell what was requested?

89
00:05:18.275 --> 00:05:21.514
Does the review explain which
changes are accepted and rejected?

90
00:05:21.839 --> 00:05:25.554
Can you distinguish an illustrative
output line from a real command result?

91
00:05:25.879 --> 00:05:28.120
Are physical unknowns still visible?

92
00:05:28.445 --> 00:05:31.510
Correct any gap that would
force the next person to guess.

93
00:05:31.893 --> 00:05:34.598
Keep the corrected artifact
separate from your critique.

94
00:05:34.981 --> 00:05:37.860
A review note explaining
three problems is useful,

95
00:05:38.069 --> 00:05:41.900
but the next person also needs the
actual report or brief they should use.

96
00:05:42.342 --> 00:05:45.128
Read that final artifact
on its own once more.

97
00:05:45.453 --> 00:05:49.203
It should not require the reader to
mentally undo rejected suggestions

98
00:05:49.528 --> 00:05:52.640
or remember qualifications
hidden in an earlier paragraph.

99
00:05:53.081 --> 00:05:55.891
The result of review is a
coherent usable document,

100
00:05:56.065 --> 00:05:58.631
with its remaining unknowns
stated where they matter.

101
00:05:59.014 --> 00:06:01.138
Finish the module quiz
after the challenge.

102
00:06:01.464 --> 00:06:05.469
The questions check the same practical
distinctions: model versus agent,

103
00:06:05.620 --> 00:06:09.671
context versus permanent knowledge,
source support, synthetic evidence,

104
00:06:09.695 --> 00:06:13.154
and bounded scope. A passing
score is a self-check,

105
00:06:13.305 --> 00:06:16.719
not a certificate that hardware
has been tested. Keep your packet,

106
00:06:16.777 --> 00:06:20.492
because the next module will give these
artifacts a concrete project folder,

107
00:06:20.620 --> 00:06:22.663
toolchain, and version history.