WEBVTT

1
00:00:00.000 --> 00:00:04.168
In the previous lesson, a short reference
passage made an answer easier to check.

2
00:00:04.679 --> 00:00:08.348
Now we will look more closely at
sources, tools, and uncertainty.

3
00:00:08.731 --> 00:00:11.738
The goal is to preserve useful
information while identifying

4
00:00:11.784 --> 00:00:15.616
what the available evidence cannot
establish. This skill matters when

5
00:00:15.662 --> 00:00:19.633
an answer combines a correct rule
with a convincing invented detail.

6
00:00:20.016 --> 00:00:24.428
Open your context comparison and find
the statement about invalid input.

7
00:00:24.753 --> 00:00:28.979
The fictional BenchNote note says
an invalid sample produces FAULT

8
00:00:29.258 --> 00:00:32.903
and its numeric temperature must
not select the ordinary states.

9
00:00:33.228 --> 00:00:36.978
That is a grounded claim because we
can point to the governing sentence.

10
00:00:37.361 --> 00:00:42.272
The answer does not become stronger merely
by adding a longer explanation after it.

11
00:00:42.655 --> 00:00:45.941
Now read the original sample
answer supplied for this lesson.

12
00:00:46.185 --> 00:00:49.145
It says the invalid
fixture produces FAULT,

13
00:00:49.424 --> 00:00:54.555
three successful readings clear the fault,
and running the tests will produce a pass.

14
00:00:55.507 --> 00:01:00.325
This sample was written for instruction.
It is not a transcript of a model run.

15
00:01:00.604 --> 00:01:04.702
We will inspect each sentence
independently rather than accept or reject

16
00:01:04.749 --> 00:01:08.383
the paragraph as a whole. The
first statement matches the note.

17
00:01:08.626 --> 00:01:12.504
Keep it. The second statement supplies
a recovery count that the note never

18
00:01:12.574 --> 00:01:16.173
defines. Three might be a reasonable
design choice in some system,

19
00:01:16.324 --> 00:01:18.448
but it is not a fact about this exercise.

20
00:01:18.889 --> 00:01:22.233
Mark it unresolved and ask for
the intended recovery requirement.

21
00:01:22.616 --> 00:01:26.691
That leaves a small, actionable question
instead of hiding a decision inside

22
00:01:26.726 --> 00:01:30.476
an explanation. The third statement
contains two different things.

23
00:01:30.987 --> 00:01:35.712
Run the tests is a proposed action.
They will pass is a predicted result.

24
00:01:36.153 --> 00:01:39.102
Neither is evidence that a
command actually executed.

25
00:01:39.543 --> 00:01:42.840
A terminal result would need the
command, its working directory,

26
00:01:43.049 --> 00:01:46.207
the source version, the input,
and the observed outcome.

27
00:01:46.648 --> 00:01:51.165
The same word PASS can appear in an
illustrative answer and a real test log,

28
00:01:51.490 --> 00:01:53.092
so provenance matters.

29
00:01:53.336 --> 00:01:56.516
This is why we inspect action
records in an agent interface.

30
00:01:57.027 --> 00:02:01.915
A model can generate text. An
agent may also use permitted tools.

31
00:02:02.298 --> 00:02:04.806
The tool result tells us
more about what occurred,

32
00:02:05.015 --> 00:02:09.543
but we still need to interpret its
scope. A successful compiler invocation

33
00:02:09.613 --> 00:02:14.257
in the wrong folder does not establish
that the intended change builds.

34
00:02:14.861 --> 00:02:17.531
A test executable left
over from an earlier source

35
00:02:17.566 --> 00:02:20.596
version can create a similarly
misleading impression.

36
00:02:21.107 --> 00:02:24.091
Use a short evidence record
rather than a long narrative.

37
00:02:24.532 --> 00:02:27.759
Name the source or command,
state what it supports,

38
00:02:27.910 --> 00:02:29.779
and note the remaining limitation.

39
00:02:29.954 --> 00:02:33.181
For example, the supplied
note documents the fault rule.

40
00:02:33.506 --> 00:02:36.862
A host test can check the implemented
rule for controlled input.

41
00:02:37.245 --> 00:02:40.983
A firmware cross-build checks
compilation for the selected target.

42
00:02:41.308 --> 00:02:45.487
A physical measurement requires an
actual physical setup and observation.

43
00:02:45.998 --> 00:02:49.295
Sources need scrutiny too.
A link is not enough if

44
00:02:49.353 --> 00:02:52.674
it points to the wrong board
variant or an unrelated section.

45
00:02:53.115 --> 00:02:56.494
Open the primary document
and identify the exact part,

46
00:02:56.737 --> 00:03:00.104
revision when available, and
the relevant sentence or table.

47
00:03:00.383 --> 00:03:02.740
A search result can help
you locate a document,

48
00:03:02.891 --> 00:03:05.747
but its short snippet may
omit conditions, units,

49
00:03:05.781 --> 00:03:09.439
or exceptions that change the
meaning. Consider a pin claim.

50
00:03:09.682 --> 00:03:13.572
The assistant recognizes a board
family and supplies a familiar number.

51
00:03:13.955 --> 00:03:17.589
Your next action is to inspect the
exact board pinout or schematic.

52
00:03:17.972 --> 00:03:22.419
Record where the value appears and which
variant it describes. Do not take two

53
00:03:22.488 --> 00:03:26.517
assistants repeating the same number as
equivalent to a checked primary reference.

54
00:03:26.900 --> 00:03:29.350
They may share the same
mistaken association.

55
00:03:29.861 --> 00:03:32.264
A retrieved document
can improve freshness,

56
00:03:32.543 --> 00:03:35.062
but retrieval is not
automatic verification.

57
00:03:35.387 --> 00:03:38.673
The assistant might find the right
manual and read the wrong column.

58
00:03:39.056 --> 00:03:42.144
It might confuse a typical
value with a guaranteed limit.

59
00:03:42.469 --> 00:03:45.104
You still need to connect
the claim to its conditions.

60
00:03:45.430 --> 00:03:48.007
Later we will practice this
in a constraints table,

61
00:03:48.123 --> 00:03:51.444
where values, units, sources,
and unknowns stay together.

62
00:03:52.047 --> 00:03:55.043
Return to the sample answer
and add a physical claim:

63
00:03:55.484 --> 00:03:57.458
the sensor cable is disconnected.

64
00:03:57.783 --> 00:04:00.906
Our input was a deliberately
authored synthetic tuple.

65
00:04:01.150 --> 00:04:04.935
It cannot establish the state of
a cable. Even an invalid physical

66
00:04:05.004 --> 00:04:08.952
reading would not uniquely identify
that cause without another check.

67
00:04:09.277 --> 00:04:13.479
A disconnected cable, failed
conversion, wrong configuration,

68
00:04:13.526 --> 00:04:17.566
or deliberate fault injection might
lead to similar software symptoms.

69
00:04:18.007 --> 00:04:21.757
A useful hypothesis names what would
distinguish it from alternatives.

70
00:04:22.268 --> 00:04:26.993
For a software exercise, inspect the
validity field and the parser result.

71
00:04:27.435 --> 00:04:28.770
For optional bench work,

72
00:04:28.886 --> 00:04:31.893
choose an appropriate observation
of the actual interface.

73
00:04:32.334 --> 00:04:36.363
Do not call a hypothesis the root cause
until evidence supports that decision.

74
00:04:36.804 --> 00:04:38.940
This keeps debugging
from becoming a series

75
00:04:38.998 --> 00:04:41.669
of guessed edits that
conceal the original symptom.

76
00:04:42.110 --> 00:04:45.767
Now rewrite the answer. Preserve
the supported FAULT rule.

77
00:04:46.046 --> 00:04:49.320
State that recovery is unspecified
in the introductory note.

78
00:04:49.564 --> 00:04:53.685
Propose checking the implemented policy
after its requirement is defined.

79
00:04:54.010 --> 00:04:58.120
Label the input synthetic and avoid
the cable conclusion. The corrected

80
00:04:58.178 --> 00:05:02.288
answer can be shorter than the original
while carrying more reliable information.

81
00:05:02.671 --> 00:05:06.828
In your exercise table, use separate
fields for documented, inferred,

82
00:05:06.863 --> 00:05:11.367
tested, and unresolved. These labels
can change as evidence arrives.

83
00:05:11.878 --> 00:05:15.535
A document-dependent value can
become documented after inspection.

84
00:05:15.860 --> 00:05:19.471
A proposed command can become an
executed check after a real run.

85
00:05:19.912 --> 00:05:23.976
An unresolved physical claim remains
unresolved if no physical observation

86
00:05:24.022 --> 00:05:28.051
occurs, even when all software
checks pass. Before finishing,

87
00:05:28.086 --> 00:05:32.370
ask whether another person could follow
your next action without guessing. Locate

88
00:05:32.393 --> 00:05:36.155
the recovery requirement is
clear. Verify everything is not.

89
00:05:36.596 --> 00:05:40.091
Run the named host test from the
recorded project root is clear.

90
00:05:40.474 --> 00:05:42.064
Make sure it works is not.

91
00:05:42.447 --> 00:05:46.348
Concrete checks turn uncertainty into
work you can schedule and review.

92
00:05:46.790 --> 00:05:51.306
When you save a source reference, include
enough detail to relocate the evidence.

93
00:05:51.817 --> 00:05:55.787
A title and section are more helpful
than a bare link to a large manual.

94
00:05:56.112 --> 00:05:59.641
For a table, keep units and
conditions with the value.

95
00:06:00.083 --> 00:06:04.065
If the page changes later, your record
explains what proposition you relied

96
00:06:04.123 --> 00:06:07.989
on and when you checked it. That
makes maintenance a focused comparison

97
00:06:08.105 --> 00:06:11.785
instead of another open-ended search
for something that sounds familiar.

98
00:06:11.994 --> 00:06:15.314
Complete the short revised answer
and keep it with the source/check

99
00:06:15.372 --> 00:06:18.391
table. You are ready for the
next lesson when you can explain

100
00:06:18.461 --> 00:06:22.559
which statement is supported, which
is invented, which is proposed,

101
00:06:22.640 --> 00:06:26.100
and which would need a new observation.
We will use those distinctions

102
00:06:26.147 --> 00:06:29.397
to write a task brief whose success
is visible from the beginning.