WEBVTT

1
00:00:00.000 --> 00:00:05.038
Verification is useful when its claims are
as precise as its checks. In this lesson,

2
00:00:05.189 --> 00:00:09.288
we will turn your test and replay
results into a concise evidence report.

3
00:00:09.799 --> 00:00:14.071
We will also identify the physical
questions those results do not answer.

4
00:00:14.582 --> 00:00:18.262
Start with the actual checkpoint-seven
receipts from the previous lessons.

5
00:00:18.541 --> 00:00:21.769
You do not need a board to
complete the core report. A host

6
00:00:21.827 --> 00:00:25.043
assertion checks software
behavior for controlled cases.

7
00:00:25.554 --> 00:00:30.836
A replay runs synthetic events through the
adapter, shared policy, and output path.

8
00:00:31.277 --> 00:00:35.399
A firmware cross-build checks source
against a selected target and toolchain.

9
00:00:35.782 --> 00:00:39.973
These are three useful forms of evidence,
but they establish different things.

10
00:00:40.414 --> 00:00:44.618
Combining them into a vague statement that
the sensor works loses the distinctions

11
00:00:44.664 --> 00:00:48.379
an engineer needs. Open
one actual test record.

12
00:00:48.820 --> 00:00:51.711
Identify the source or
checkpoint, command,

13
00:00:51.781 --> 00:00:55.380
input conditions, process result,
and relevant assertions.

14
00:00:55.891 --> 00:00:58.933
A statement such as the
stale-boundary test rejected

15
00:00:58.967 --> 00:01:02.137
the seeded comparison is
supported when the record shows

16
00:01:02.195 --> 00:01:05.306
the compiling wrong source
and the behavioral failure.

17
00:01:05.690 --> 00:01:10.380
A final passing line by itself does not
establish the mutation part of that claim.

18
00:01:10.984 --> 00:01:15.291
Now open a replay record. The
inputs are explicitly synthetic.

19
00:01:15.570 --> 00:01:18.322
The program executes real software logic,

20
00:01:18.438 --> 00:01:21.189
but the temperatures did not
come from a physical sensor.

21
00:01:21.433 --> 00:01:25.903
The injected timestamps are controlled
inputs rather than measured device timing.

22
00:01:26.228 --> 00:01:29.003
This is a strong way to
reproduce a software sequence,

23
00:01:29.212 --> 00:01:32.811
provided the result remains labeled
according to its actual origin.

24
00:01:33.136 --> 00:01:35.923
Consider the firmware-build
receipt. It needs the source

25
00:01:35.957 --> 00:01:39.406
identity and the selected target
inputs as well as the command result.

26
00:01:39.847 --> 00:01:42.494
A successful cross-build
establishes that the source

27
00:01:42.541 --> 00:01:44.944
compiled and linked
under those conditions.

28
00:01:45.455 --> 00:01:50.029
It does not establish that the program
was uploaded, that USB enumeration worked,

29
00:01:50.238 --> 00:01:53.315
or that a physical device
behaved correctly after startup.

30
00:01:54.127 --> 00:01:59.282
Use three columns in your report: claim,
evidence, and limitation. The claim

31
00:01:59.341 --> 00:02:03.195
should be a complete statement. The
evidence should point to a real record.

32
00:02:03.474 --> 00:02:07.944
The limitation should identify what a
reader might otherwise infer incorrectly.

33
00:02:08.547 --> 00:02:13.412
For example, shared-policy host tests
support behavior for their cases,

34
00:02:13.656 --> 00:02:17.766
while electrical faults and sensor
accuracy remain outside their scope.

35
00:02:18.149 --> 00:02:19.937
Be careful with the word fault.

36
00:02:20.262 --> 00:02:24.360
In the program, fault is a state that
can be the correct response to missing,

37
00:02:24.604 --> 00:02:28.494
nonfinite, or stale input.
A valid replay fixture

38
00:02:28.540 --> 00:02:32.441
can intentionally reach that
state and still exit successfully.

39
00:02:32.824 --> 00:02:35.855
The program did its job by
reporting the condition.

40
00:02:36.238 --> 00:02:40.139
Treating every fault state as a broken
test would encourage you to remove

41
00:02:40.173 --> 00:02:43.529
the very cases that demonstrate
useful error handling.

42
00:02:43.912 --> 00:02:45.746
A malformed fixture is different.

43
00:02:46.071 --> 00:02:49.821
If its numeric token or row
structure violates the input grammar,

44
00:02:50.030 --> 00:02:54.070
the parser rejects the file with a
line-number diagnostic and exit two.

45
00:02:54.454 --> 00:02:56.961
A failed assertion is
another distinct result,

46
00:02:57.205 --> 00:03:01.338
reported by the test executable
with exit one. The report should say

47
00:03:01.396 --> 00:03:05.970
which outcome occurred instead of using
one undifferentiated word for all of them.

48
00:03:06.481 --> 00:03:10.986
Look at the supplied overclaim: replay
passed, so the board is verified.

49
00:03:11.497 --> 00:03:13.807
Correct it by naming the actual result.

50
00:03:14.190 --> 00:03:18.370
State that the recorded synthetic replay
matched the expected software behavior

51
00:03:18.439 --> 00:03:22.004
for the checked source and inputs,
if that is what the evidence shows.

52
00:03:22.247 --> 00:03:25.928
Then list the physical checks that
were not performed. This correction

53
00:03:25.997 --> 00:03:29.597
preserves the useful success while
removing an unsupported inference.

54
00:03:30.038 --> 00:03:34.287
An optional physical-check list can be
prepared without pretending it happened.

55
00:03:34.612 --> 00:03:38.513
It may include exact board and
breakout revision, acquisition-adapter

56
00:03:38.559 --> 00:03:43.076
initialization, missing-sensor
behavior, upload and serial operation,

57
00:03:43.204 --> 00:03:46.269
recovery, timing, and an
appropriate measurement method.

58
00:03:46.780 --> 00:03:51.482
Mark those items as unperformed unless
actual separate evidence exists.

59
00:03:51.807 --> 00:03:54.651
The core course does not
require them to be completed.

60
00:03:54.930 --> 00:03:58.308
Do not confuse a manufacturer
document with a bench result.

61
00:03:58.749 --> 00:04:02.650
A source can establish a board
feature or a documented interface,

62
00:04:02.929 --> 00:04:06.853
but it does not show the jumper position
or wiring of an unobserved unit.

63
00:04:07.457 --> 00:04:11.172
Likewise, a plausible temperature
is not a calibration result.

64
00:04:11.613 --> 00:04:14.980
Each claim needs a procedure
suited to the question it asks.

65
00:04:15.421 --> 00:04:18.765
Review source identity before
reusing a passing receipt.

66
00:04:19.206 --> 00:04:23.687
An old result can remain accurate history
while failing to certify a later edit.

67
00:04:24.071 --> 00:04:26.497
Record what changed after
the check and decide

68
00:04:26.532 --> 00:04:28.528
which verification is still relevant.

69
00:04:29.039 --> 00:04:33.277
A wording-only correction may leave
policy results unaffected, while

70
00:04:33.312 --> 00:04:37.329
a changed comparison requires repeating
the behavior cases that depend on it.

71
00:04:37.933 --> 00:04:41.079
Your exercise is to write
three supported software claims

72
00:04:41.288 --> 00:04:45.142
and three unperformed physical
claims with their missing evidence.

73
00:04:45.653 --> 00:04:49.333
Correct the replay-to-board overclaim
and explain the difference between

74
00:04:49.392 --> 00:04:53.188
policy fault, fixture parsing
failure, and assertion failure.

75
00:04:53.513 --> 00:04:55.800
Submit the report with
accessible receipts.

76
00:04:56.184 --> 00:05:00.270
Do not create invented physical data
to make every row look complete.

77
00:05:00.595 --> 00:05:03.289
State the caller contract
when it affects a claim.

78
00:05:03.533 --> 00:05:07.515
The snapshot accessor reports
stored policy state; time-dependent

79
00:05:07.561 --> 00:05:11.926
freshness must be updated through
polling or acquisition before inspection.

80
00:05:12.623 --> 00:05:15.525
A test that skips that
required step may ask

81
00:05:15.572 --> 00:05:18.114
a different question from
the documented behavior.

82
00:05:18.625 --> 00:05:21.737
Include such preconditions in
the requirement-to-check map

83
00:05:22.062 --> 00:05:24.767
rather than hiding them in
an implementation detail.

84
00:05:25.464 --> 00:05:26.718
If a receipt is missing,

85
00:05:26.996 --> 00:05:30.212
say that the claim is not
established by the available record.

86
00:05:30.595 --> 00:05:34.009
You can rerun a relevant check
when the environment is available,

87
00:05:34.183 --> 00:05:35.994
but label that as a new result.

88
00:05:36.273 --> 00:05:40.905
A reconstructed present check does not
recreate an earlier unrecorded run.

89
00:05:41.230 --> 00:05:45.224
This distinction matters when a handoff
or release note has carried a confident

90
00:05:45.271 --> 00:05:49.090
but unsupported statement forward.
Pause here to complete the report.

91
00:05:49.532 --> 00:05:53.119
A reviewer should be able to select
any claim and identify the evidence

92
00:05:53.142 --> 00:05:56.649
that supports it, the source it
applies to, and the important limits.

93
00:05:57.159 --> 00:06:00.329
The report should remain readable
without tiny screenshot text.

94
00:06:00.840 --> 00:06:04.230
Screenshots illustrate genuine
results, while the written commands

95
00:06:04.265 --> 00:06:07.654
and interpretation keep the procedure
searchable and reproducible.

96
00:06:08.096 --> 00:06:12.124
Finish by explaining the shared-source
diagram in one sentence of your own.

97
00:06:12.565 --> 00:06:16.478
The same policy implementation is
exercised through host and firmware build

98
00:06:16.536 --> 00:06:20.623
paths, while physical acquisition
remains a separately validated extension.

99
00:06:20.948 --> 00:06:23.328
Honest scope is part of
the engineering result.

100
00:06:23.572 --> 00:06:27.299
You now have a verification report
that supports the next task without

101
00:06:27.345 --> 00:06:30.886
asking another person to trust a
label that says everything passed.